Showing 1–11 of 11 dossiers

AWS Lambda can now reference deployment packages directly from your S3 bucket

AWS has added a `REFERENCE` mode for Lambda deployment packages. It eliminates duplicate managed copies, raises the default managed-storage quota to 300GB, and gives teams direct control over encryption, lifecycle and audit policy—but a deleted or inaccessible source object can now make a function inactive.

GitLab 19.3 turns plain-English process knowledge into runnable agentic flows

Custom Flows became generally available in GitLab 19.2; 19.3 adds the missing authoring layer. Flow Creator reads current Flow Registry docs, applies known failure rules and generates a runnable flow from plain English. Builders still need to review, register and govern the automation rather than treating generated YAML as trusted infrastructure.

Railway Cloud Agents turn coding agents into persistent deployment-adjacent VMs

Railway Cloud Agents are managed, persistent development machines rather than a new model or harness. They reuse developers’ existing agent credentials, sleep when disconnected by default, retain disk state, and live inside Railway project environments—blurring the boundary between remote coding workspace and deployment platform.

Neon makes Functions and Object Storage branch with Postgres

Neon’s beta backend now combines Postgres branches with Node.js Functions and S3-compatible Object Storage that inherit branch semantics. For builders, that makes ephemeral preview/test environments more complete: database state, backend code and object data can move together instead of requiring separate production-adjacent services.

Deployment systems turn code into a running service, and small workflow changes can have large effects on reliability and developer time. Containers, CI pipelines, infrastructure tools and platform abstractions each promise repeatability, but they also define who can change production and how failures are recovered.

This page follows deployment and DevOps developments that materially improve or complicate that path. BTN examines migration effort, security boundaries, portability and operating cost alongside feature claims. The focus is on practices and tools proportionate to the team using them. A useful change should make shipping safer or simpler, not merely add another control plane whose maintenance becomes a job of its own.

Security and rollback are recurring tests for every deployment improvement. BTN looks for clear permissions, reviewable changes and a route back when automation produces the wrong result. Faster pipelines are valuable, but confidence comes from knowing what ran, what changed and how production can be restored.