Product changelog

The latest features, improvements, and bug fixes.

Search titles, descriptions, products, and versions.

Change type

Rapids

13 updates

Version 2.9.118

Bug fixRapids

Rapids API Rejects Environment Variables Sent as a List

Sending a Rapids container's environment variables as a list of KEY=VALUE strings is now refused up front, instead of being accepted and then failing every rollout.

  • Creating or updating a container with environment_variables as a JSON list of KEY=VALUE strings now returns 422 with a message asking for name and value pairs; it used to return 200, and every later rollout then failed
  • Each variable name may use only letters, digits, underscores, hyphens and dots, or the request returns 422 for that variable; reserved names and the 100 KB limit are unchanged
Show 2 more changes
  • A container that already stored its variables as a list now fails its deploy with a message asking you to save them again as name and value pairs
  • A change that fails partway is now discarded completely, so it can no longer reach your running container later and take it down

Version 2.9.112

ImprovementRapids

A Rebuilt Rapids Console With Live Traffic and Drawers

The container list and container page were rebuilt around what matters day to day: live traffic at a glance, builds and domains in drawers, and one form for create and edit.

  • Every row in the container list shows live replicas, requests, latency, errors and this month's cost, and search and the status filter cover all your containers, not only the page on screen
  • The list totals for containers, running replicas, requests a minute and this month's cost are now accurate; they used to read zero
Show 4 more changes
  • Each container page opens with a summary of its address, what is serving, replicas and live traffic, including requests a minute, p95 latency and error rate, refreshed every few seconds
  • Builds open in a drawer with a live log that jumps to the first error, and domains open in a drawer showing each domain's state, the next step and its exact DNS records
  • Create and Edit share one single-page form: errors point to the section to fix, a save bar says whether saving rolls out, rebuilds or switches source, and an image entered as nginx:1.27 deploys that tag instead of latest
  • Average latency is now recorded for every usage window, so it no longer shows blank in the list and the API
Read documentation (opens in a new tab)

Version 2.9.111

ImprovementRapids

Faster Rapids Builds, Plus an Optional Build Cache

Deploys start seconds after a build finishes, builds get more CPU headroom, and you can keep a build cache per container to speed up the next build.

  • A finished build now starts its deploy within seconds instead of waiting up to a minute
  • Builds get twice the CPU headroom, so toolchains that use every core, such as Next.js, finish sooner
Show 3 more changes
  • Dockerfile builds now run on a new builder, with no change needed on your side
  • Turn on Keep the build cache for a container that builds from a Dockerfile to reuse its image layers and cache mounts, so later builds finish faster; the API field is build_cache_enabled
  • The cache only ever saves time: if it is not available the build runs without it, and a cache unused for 14 days is removed
Read documentation (opens in a new tab)

Version 2.9.105

Bug fixRapids

Rapids Fixes: Custom Domains, Rollbacks and Auto-Build

Custom domains no longer hold up your deploys, routing traffic back to an earlier revision really moves it, and turning auto-build off really stops push builds.

  • A custom domain whose certificate is still being issued no longer blocks every later deploy of its container
  • A domain shows as set up only once it really exists; while a change is being applied it stays pending and finishes on its own
Show 4 more changes
  • One inconsistent DNS answer no longer fails a domain, a failed domain is retried automatically after 15 minutes, and removing a domain after deleting its DNS record no longer leaves its certificate cleanup stuck
  • Route traffic here on an earlier revision now really sends all traffic to it without a rebuild, and the console shows it as current only once the switch has happened
  • With Auto-build on push turned off, pushes to your branch no longer start builds; manual and API builds still work
  • Status badges read Building, Deploying and Degraded instead of a generic Pending, and pressing Enter in an early field of the create form no longer submits it

Version 2.9.103

FeatureRapids

Rapids Runs: One-Off and Scheduled Jobs From Your Container's Image

Run your Rapids container's image exactly once, on demand or on a cron schedule, for a migration, backfill or maintenance script, without touching the replicas that serve your traffic.

  • Start a run from the new Runs tab on your container's page, from the API or with the danube CLI; it uses your container's image and environment, and you can add per-run environment variables, choose an image tag and set a timeout of up to an hour
  • Only one run is active per container at a time, apart from the replicas serving traffic, so a migration never runs twice or concurrently
Show 5 more changes
  • Schedule runs with a standard cron expression in your own timezone; a run that comes due while the previous one is still going is skipped and recorded, not stacked
  • Follow a run's log live in a drawer, and read the last lines of its output for 10 days after it finishes
  • The Command field splits arguments the way a shell does, so a quoted argument stays in one piece, and leaving it empty asks you to confirm before the image's own startup command runs
  • A run is billed like one of your container's replicas, at the same vCPU-second and GiB-second rates with the same monthly free tier, from the moment it starts until it exits, with no separate run charge
  • Get a webhook when a run succeeds or fails, and call your own container from a run through its internal URL
Read documentation (opens in a new tab)

Version 2.9.98

ImprovementRapids

Rapids Updates Always Land, and Startup Work Runs Once

Changes sent during a rollout are never dropped, a rollout only counts as done once its own revision is ready, and two new settings stop startup work such as migrations from running twice.

  • An update sent while a rollout is still running is queued and applied next instead of being silently dropped, and several quick changes roll out together
  • Your change reads as queued until its rollout starts, and a rollout counts as finished only once its own new revision is ready, so danube rapids update --wait (CLI 1.3.0 or later) returns only when your change is live
Show 4 more changes
  • A rollout whose new revision never appears now fails after 20 minutes with a clear message instead of staying in Deploying
  • Retrying a rollout no longer creates an extra revision, so startup work does not run again
  • New Initial scale and Scale-down delay settings, under Resources and scaling in the Advanced section and in the API and CLI, let a container that migrates on boot avoid doing that work on two revisions at once
  • Deployment history no longer marks healthy older revisions as failed, and health alerts skip retired revisions and name the image you actually deployed
Read documentation (opens in a new tab)

Version 2.9.92

ImprovementRapids

New Rapids Egress Address to Allowlist: 178.63.243.79

Rapids containers can now also connect out from 178.63.243.79, so add it wherever you allowlist our egress addresses.

  • 178.63.243.79 has joined the published list of IPv4 addresses Rapids containers connect out from
  • It started carrying traffic on 14 September as emergency capacity, the documented exception to our 14-day notice for new egress addresses
Show 3 more changes
  • If you allowlist Rapids by IP at a firewall, CDN, WAF or database, add it now, or requests leaving from it may be rejected
  • Scripts that read docs.danubedata.ro/rapids-egress-ips-v4.txt already have it
  • If you do not allowlist by IP address, there is nothing to do
Read documentation (opens in a new tab)

Version 2.9.81

Bug fixRapids

Resource Profiles Apply and Failed Builds Show Why

The profile you pick now sets the container CPU and memory it actually runs with, and a source build that fails no longer sits in Building forever.

  • Choosing a resource profile sets the container CPU and memory requests and limits accordingly; previously every container ran with the same defaults regardless of profile
  • The container page shows the CPU and memory it actually runs with, and the API exposes a metrics endpoint plus the same values on the container resource
Show 2 more changes
  • A source build whose checkout or build step fails is marked Build failed, with the reason, recovery guidance and a link to the failed build
  • Builds are reconciled against the build system, so a lost callback can no longer leave a container stuck
Read documentation (opens in a new tab)

Version 2.9.63

FeatureRapids

Deployment Diagnostics Built for the CLI and AI Agents

Rapids now reports a truthful, machine-readable deployment state with a typed reason, plus APIs for logs, revisions and events — so a script or coding agent can diagnose a failed deploy without opening the dashboard.

  • Deployment status is machine-readable, with typed detail explaining exactly what went wrong
  • New API endpoints for container logs, revisions and events
Show 4 more changes
  • Registry credentials are attached automatically when you deploy from your private registry
  • A registry context endpoint and push preflight tell you where to push and whether it will succeed
  • POST /serverless accepts an Idempotency-Key, so a retried create never produces a second container
  • A container in a degraded state can now be edited to fix it, instead of being stuck
Read documentation (opens in a new tab)

Version 2.9.61

ImprovementRapids

Your Containers Now See the Real Visitor IP

The originating client address is preserved all the way to your container, so rate limiting, geolocation and IP allowlists work on real addresses.

  • X-Forwarded-For now carries the real client IP rather than an internal address
  • Rate limiting and abuse controls inside your app operate on genuine addresses
Show 3 more changes
  • Geolocation and analytics see the visitor rather than our load balancer
  • Works for both IPv4 and IPv6 visitors
  • Read the chain from the right and take the first public address — the docs show the exact snippet
Read documentation (opens in a new tab)

Version 2.9.57

FeatureRapids

Readiness Probes and a Startup Deadline for Your Containers

Tell us the HTTP path that means your container is ready, and how long it is allowed to take getting there.

  • Opt-in HTTP readiness probe — set the path, port and timing
  • Set a startup deadline so a slow-booting container is given the time it needs
Show 3 more changes
  • Traffic only reaches a revision once its readiness probe passes
  • A container that never becomes ready fails the deploy instead of quietly serving errors
  • Configurable on both the create and edit forms
Read documentation (opens in a new tab)

Version 2.9.48

FeatureRapids

Allowlist Rapids: Published Egress IP Addresses

The public IPv4 addresses your Rapids containers make outbound connections from are now documented, so you can allowlist them on a third-party database or API.

  • Published list of the IPv4 addresses Rapids containers egress from
  • Machine-readable at docs.danubedata.ro/rapids-egress-ips-v4.txt for use in automation
Show 2 more changes
  • Allowlist Rapids on an external database, payment provider or partner API
  • We continuously check for drift and are alerted if traffic ever leaves from an undisclosed address
Read documentation (opens in a new tab)

Version 2.4.3

ImprovementRapids

Smarter ZIP uploads & editable build config

Several quality-of-life upgrades to Rapids ZIP-upload deployments — wrapper-folder zips just work, build settings are editable after creation, and the upload form now tells you what is happening.

  • Auto-unwrap single-folder ZIPs — no more "Dockerfile not found" when you used `zip -r foo.zip myproject/`
  • Friendlier build errors that point you to the wrapper-folder fix when manifest files are missing
Show 4 more changes
  • Edit build configuration after creation — switch between Buildpacks and Dockerfile, change the Dockerfile path, source directory, or buildpack builder. Saving rebuilds from your last upload
  • Post-upload "Follow build" + "Cancel build" buttons replace the upload form so it is clear a build is running
  • Reserved-port validation: friendly error if you pick a port already in use by the platform, with a documented reserved list
  • Uploaded ZIPs are now kept in object storage, so manual rebuilds and Retry no longer require re-uploading
Read documentation (opens in a new tab)

Get notified of updates

Subscribe to receive notifications about new features, improvements, and important updates.