October fixes and improvements
Rollouts that wait for slow first boots but fail fast when they cannot start, safer volumes, and a round of build and dashboard fixes.
Deploys
- A new version gets up to 10 minutes to become ready, enough for migrations, a JVM or an app that installs itself on first boot.
- A version that cannot start fails right away with the reason: an image that cannot be pulled, an invalid container configuration, repeated out-of-memory restarts or a crash loop.
- A deploy queued during a rollout, or right after a cancel, is accepted instead of failing with “Service is changing state”.
- A cancelled deploy stops waiting for its rollout.
- GitHub deployment statuses no longer stay on “In progress” after the deploy has finished.
- Switching a health check between HTTP and TCP no longer fails the deploy.
Builds
- Bun monorepos that build from the repository root keep every workspace’s production dependencies, and the generated Prisma client survives the production install.
- Static sites serve their own
404.htmlfor unknown pages, and a 404 is never cached by the CDN.
Volumes and databases
- A service always keeps its own volume across deploys, regardless of how storage is laid out on the cluster.
- The MySQL template fits in its memory limit.
Dashboard and billing
- The start command of an image service can be edited from its Container settings.
- Subscriptions are paid through a secure Stripe Checkout page, then you return to Billing.
- Project cards keep a fixed height and room for their status label.
- Server lists from external providers retry briefly when the provider is slow, and keep the last known data instead of showing an error.