Loading…
Topic
160 posts about Deployment. Every summary links to the original.
See the idea
A/B testing trades traffic, time, and exposure risk for evidence. This explainer maps the benefit of a controlled comparison, the real cost of running one, and the condition that decides when measuring beats shipping on judgment.
Bun packs a runtime, package manager, bundler, and test runner into one binary. Here is how those four parts fit together and where the seams still show.
CloudFormation is a declarative reconciler: you describe the target state in a template, and it provisions, updates, and reports on the stack that results. Here is the loop.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Cursor’s Cloud Agents let developers run multiple agents remotely without keeping a laptop connected to the internet. Agents can be launched and managed from the Cursor editor, cursor.com/agents, Slack, Linear, and GitHub, supporting background bug fixes, small todos, and larger feature work. For difficult bugs, the team commonly has multiple models attempt the same problem and selects the best result; for complex features, a locally developed plan can be sent to a cloud agent for implementation, allowing work to continue on another task. Cursor also revamped its GPT-5 Codex agent harness for longer time horizons in the cloud, while plan mode supports sending implementation plans remotely. The workflow is available today in Cursor editor and Cursor Web, as well as the listed integrations.
Simulation in healthcare robotics has historically been slow, siloed, and difficult to translate into real-world physical systems. The NVIDIA Isaac for Healthcare v0.4 release introduces an end-to-end SO-ARM starter workflow to streamline simulation, training, and deployment for embodied surgical assistants. The architecture relies on a Sim2Real mixed training approach that fine-tunes the GR00T N1.5 foundation model on combined real-world and synthetic datasets using LeRobot. Synthetic data generated in simulation constitutes over 93 percent of the policy training data to bridge physical data collection constraints. Real-time inference on the SO-ARM101 precision manipulator utilizes RTI DDS communication, dual-camera vision, and TensorRT model conversion.
Simulation in healthcare robotics has historically been slow, siloed, and difficult to translate to physical hardware. NVIDIA introduced the Isaac for Healthcare v0.4 developer framework to streamline this lifecycle through an end-to-end SO-ARM starter workflow. Developers collect mixed real-world and synthetic datasets using LeRobot and SO-101 teleoperation, with synthetic generation accounting for over 93 percent of training data. The pipeline post-trains GR00T N1.5 models using dual-camera vision inputs, evaluates policies in Isaac Lab, and deploys them to physical hardware with RTI DDS communication. This integrated approach allows surgical assistant robots to interpret natural language instructions and execute physical manipulation tasks reliably.
Scaleway is integrated as a supported serverless Inference Provider on the Hugging Face Hub, expanding model deployment options across Hub model pages and official client SDKs for JavaScript and Python. Operating out of European data centers located in Paris, France, Scaleway Generative APIs host open-weight models including gpt-oss, Qwen3, DeepSeek R1, and Gemma 3 with structured outputs, function calling, multimodal processing, and sub-200ms first-token response times. Developers can route inference requests using their Hugging Face tokens or supply direct Scaleway API keys. Billing for routed requests charges standard provider rates starting at €0.20 per million tokens without markups, while direct requests bill to Scaleway accounts. Hugging Face PRO subscribers receive two dollars of monthly inference credits applicable across providers.
Fly.io is consolidating its region map and deprecating 17 regions across North America, Europe, Asia-Pacific, South America, and Africa. The announcement lists 17 deprecated locations, including Madrid, Bucharest, Warsaw, Atlanta, Boston, Denver, Guadalajara, Miami, Phoenix, Querétaro, Seattle, Montreal, Bogotá, Ezeiza, Rio de Janeiro, Santiago, and Hong Kong, and names 18 consolidated regions: seven in North America, five in Europe, four in Asia-Pacific, and one each in South America and Africa. For apps migrated by Fly.io, most moves should be seamless, although applications with region-specific logic must be updated to use the new region. Manual moves generally require changing primary_region in fly.toml, scaling up in the destination with fly scale count, and scaling down in the original region. If volumes are involved, the guidance recommends stopping existing machines, forking volumes into the new region, and creating machines from those forks; support is offered for issues that arise.
Grab describes how it evolved its machine learning feature store as increasingly complex models began requiring high-cardinality keys and high-dimensional data. It replaced its initial Amphawa approach with feature tables: data-lake tables whose contents are atomically ingested into serving storage, with emphasis on consistency and reproducibility. The workflow stores feature tables and version-control metadata as Parquet objects in Amazon S3, validates schemas, loads data through reverse ETL into Aurora Postgres, and warms new tables through shadow reads before switching. The redesign supports contextual retrieval, atomic collection-wide updates, and isolation between reading and writing capacity; its SDK remains a thin database-driver wrapper that translates queries to SQL. Grab also chose decentralised deployments for version flexibility, rollout strategies, noisy-neighbor mitigation, and improved caching, concluding that Amazon Aurora for Postgres provides a robust, scalable, cost-effective foundation.
Sam Ruby describes publishing an online guide to using Kamal 2.0 for production after finding existing material insufficient for deploying a real project. The guide grew from research for the Deployment and Production chapter of Agile Web Development with Rails 8, then was converted from Pragmatic Programming’s XML grammar to Markdown with GitHub Copilot and proofread with it. It presents an opinionated starter list with defaults and alternatives, covering seven initial requirements alongside Docker builders, container repositories, secret management, hosting choices, load balancing, and managed databases. It also treats production as including database backups, searchable logs, monitoring, and application security, and invites community corrections or additions under a CC0 license.
Heroku’s Java buildpacks simplify JVM application deployment by detecting project languages and frameworks, fetching build tools, and configuring runtime settings automatically. They support Spring Boot, Quarkus, and Micronaut by inspecting Maven or Gradle build definitions, packaging applications, selecting framework-specific runner commands, and mapping service variables such as SPRING_DATASOURCE_URL, SPRING_REDIS_URL, DATABASE_URL, and JDBC_DATABASE_URL. In many cases, a Procfile is unnecessary because the buildpack can identify the executable JAR and provide a default web process, while Quarkus and Micronaut receive their respective runner JAR and port settings. Heroku also automatically attaches a lightweight JVM agent for runtime metrics, including memory usage and garbage collection, and offers similar buildpack support for Scala and Clojure through sbt and Leiningen.
The article presents a production-grade approach to securing Stripe API keys in AWS, motivated by the risks and operational limits of basic secret storage for payment processing. It compares AWS Parameter Store with Secrets Manager, emphasizing built-in rotation, CloudTrail audit trails, IAM integration, larger secrets, and cross-account access despite higher cost. The implementation uses environment-specific secret paths, tags, and IAM conditions to isolate development, staging, and production credentials, with separate rotation schedules. For zero-downtime rotation, applications refresh cached credentials after authentication failures while both old and new keys remain valid during a transition. The design also covers CloudWatch monitoring, emergency rotation procedures, cross-region replication, region-specific schedules, and cost considerations, concluding that ongoing review is necessary for secure and reliable payment operations.
Grab developed and scaled Catwalk, an internal machine learning model serving platform, to address operational bottlenecks, low resource utilization, and deployment friction between data scientists and backend engineers. The platform transitioned from an admin-managed TensorFlow Serving setup into a low-code self-service system supporting PyTorch and ONNX, before replacing complex Helm charts with Kubernetes Custom Resource Definitions for declarative, blue-green deployment orchestration. To support complex business workflows and multi-model applications, Grab subsequently introduced Catwalk Orchestrator with bundled deployments that allow individual services to scale independently. Across two years, the orchestrator architecture expanded to 200 deployed applications serving approximately 1,400 production machine learning models.
Stripe integrations can become difficult to test when an account has only one test mode, because unrelated work can interfere and sensitive configuration must remain protected. The post presents Stripe Sandboxes as separate testing areas and shows a Node.js Express application authenticating with a sandbox secret key stored in a .env environment variable. It creates payment intents through /create-payment-intent and retrieves account details through /account, then uses Jest and supertest to verify the sandbox identity, including the expected display name dev-sandbox. A GitHub Actions workflow injects STRIPE_API_KEY from repository secrets, installs dependencies, and runs tests on pushes to the main branch, while .gitignore excludes environment files. The conclusion is that isolated sandboxes and automated checks reduce test tangles and help prevent calls to the wrong environment.
Grab's self-hosted GitLab instance fell approximately 14 months behind official releases, serving thousands of engineers and monorepos reaching up to 39TB in total footprint. To address security updates and system stability, the team established a structured upgrade routine using Terraform, Packer, and Ansible across GitLab's 5,000-user reference architecture. They implemented staged deployments, upgraded stateful Gitaly nodes via in-place rotation, and resolved primary node clustering bottlenecks under Praefect. By utilizing official GitLab Upgrade Paths and parallelizing component deployments, the team caught up on 24 months of releases in 11 months and reduced release lag from 396 days down to 35 days.
Fly.io introduces a streamlined version of its fly launch command for deploying applications near their users. The CLI now infers desired infrastructure from application source code and offers opinionated defaults or alternative options when it cannot apply the same shape. Previously, the launch flow asked a series of questions; the change reduces guesswork by folding varied frameworks, languages, and toolchains into a few basic infrastructure shapes. A Rails application using SQLite is given an example set of defaults that developers can build from, while other applications can be configured through a confirmation webpage. Once settings are accepted, the app is built and deployed unless --no-deploy is supplied, and the CLI provides a link to the running app.
Fly.io announces $25MM from A16Z and existing investors followed by $70MM led by EQT Ventures, and uses the occasion to explain its platform vision. Its central problem is the “two hour” barrier: ordinary tooling makes global deployment, VMs, real-time features, encryption, and clustered databases too difficult to pursue quickly, leaving many applications concentrated in us-east-1. The company’s approach is to build a hardware-backed platform and toolchain spanning many regions, with Fly Machines making on-demand VM creation as straightforward as a function call. Funding will support 33 regions, support and reliability, advanced storage, security capabilities, and new hardware while preserving a self-service experience for containerized applications. The stated user-facing promise is that an existing Docker container can run on Fly.io in single-digit minutes and reach every continent in another minute or two.
A TypeScript template for ChatGPT Plugins runs on Supabase Edge Runtime and provides a path for exposing a TODO API to ChatGPT. The implementation serves the required ai-plugin.json manifest from an Edge Function because static file hosting is not currently supported, and generates an OpenAPI JSON document from endpoint JSDoc annotations with swagger-jsdoc. An Oak router defines TODO routes, while shared CORS headers allow requests from https://chat.openai.com and credentials. Docker configuration runs Edge Runtime locally with a bind-mounted functions directory, enabling changes without rebuilding and exposing requests through localhost:8000. The guide also covers local installation and testing through the ChatGPT UI, then deployment to Fly.io; it notes authentication as a possible next step.
Stateful stream processing frameworks like Apache Flink present unique deployment challenges because conventional canary and blue-green strategies can cause data inaccuracies or state divergence. Grab's real-time data platform team encountered risks of state loss, manual rollback overhead, and absent health checks in their Kubernetes and Spinnaker deployment pipeline. To resolve these operational issues, the team redesigned the deployment workflow around automated Flink savepointing and programmatic health monitoring. The new pipeline halts existing applications after capturing state snapshots and Kafka offsets, monitors target deployments via API health probes, and executes automated rollbacks using versioned ConfigMaps and replica metadata annotations. This automated process ensures state consistency during upgrades and eliminates manual intervention during deployment failures.
database.dev is a public preview of dbdev, a PostgreSQL package manager whose registry is currently read-only and preloaded with packages demonstrating packaging and discovery possibilities. It aims to provide repeatable deployment of libraries and applications, with third-party publishing tools planned after community feedback, and uses organization- or user-namespaced package names to address name and typo squatting. The in-database client installs packages, which PostgreSQL then exposes as native extensions; dbdev adds major.minor.patch version constraints, while compatibility currently requires Supabase new projects or PostgreSQL with pg_tle and pgsql-http. Examples include a hybrid document-search backend, an index advisor that reports a sample total-cost reduction from 25.88 to 6.40, and administration views for database diagnostics. The preview depends on Trusted Language Extensions, and the post invites reports, feature ideas, and contributions while noting that pl/rust had not yet reached Supabase.
Supabase has open-sourced Edge Runtime, an MIT-licensed Rust web server built on Deno Runtime 1.32+ for self-hosting Deno Edge Functions. It serves TypeScript, JavaScript, and WASM functions, and existing Supabase Edge Functions can run without code changes; the release also adds npm modules and Node built-in APIs. The Supabase CLI uses it to serve all local functions with JWT verification, import maps, custom environment variables, hot reload, and defaults of 150 MB memory and 60 seconds execution time. Its architecture combines hyper, a Main Worker in a V8 isolate, and restricted User Workers that handle requests with controllable resource limits, while exposing APIs intended to improve development and deployment parity. A Fly.io demonstration shows deployment, with Digital Ocean and AWS also cited as provider options; the project is in beta with bugs and performance quirks still expected.
Shopify’s Merlin machine learning platform was expanded to support online inference, allowing trained models to return predictions as input arrives rather than through periodic batch jobs. The design targets varied Shopify use cases and requirements, including support for TensorFlow, PyTorch and XGBoost, low latency, autoscaling, rolling deployments, observability and model updates. Each use case runs as a dedicated service on Google Kubernetes Engine, with a Python serving layer that loads models and artifacts, exposes an inference endpoint, and can use the Comet ML model registry and Pano feature store. Separate staging and production configurations let teams tune resources and test model versions before release; Shopify reports that online inference is providing the intended low latency, scalability and faster iteration, while ensemble inference, platform-based monitoring and continuous training remain planned areas.
Grab's real-time data platform team transitioned from an Atlantis-driven Terraform workflow to an in-house GitOps platform called Khone to manage streaming infrastructure resources like Kafka topics and Flink pipelines. The earlier setup suffered from coarse-grained access controls, required manual merge request comments, and lacked flexible validation capabilities within native configuration files. Khone derives environment parameters directly from standardized directory paths and uses Python with the python-hcl2 library to inspect and validate resource definitions before executing Terraform stages in parallel. To prevent configuration tampering in merge requests, CI/CD pipeline definitions and execution scripts are isolated in a separate administrative repository and fetched during job runs using shallow Git clones.
The best engineering reads, once a week.
