Sevalla Changelog #0092 Production Gets Simpler
Introduces resilient cron jobs, and Railpack builds to help teams ship with less infrastructure work.
Establishing connection…
Signal detected.
Link established.
Baud here with a 56k Sevalla changelog transmission.
Two updates shipped over the last two weeks, all focused on removing operational friction for teams running production workloads. One makes scheduled jobs more resilient when things go wrong. The other speeds up the path from source code to a running application with a new generation of build technology.
Update - July 30th, 2026: We will disable Sevalla's rate-limiting feature on August 5th. After reviewing the implementation, we determined that we could not continue supporting it to the standard we expect from a production feature. We're sorry we announced it before confirming we could support it long-term. Customers who enabled the feature have been contacted directly.
Quick links to the updates:
Cron jobs that recover instead of getting stuck#
A scheduled job shouldn't quietly stop running because one execution never finished.
Cron processes now include two new scheduling controls that give you more predictable behavior when workloads don't go as planned.
Concurrency policy#
Choose how Sevalla handles overlapping scheduled executions.
- Forbid (the default) keeps today's behavior by skipping new runs until the current job completes.
- Replace automatically terminates a still-running job and starts a fresh execution instead. If yesterday's run hangs, the next scheduled execution clears it automatically instead of leaving your schedule blocked indefinitely.
Maximum run time#
You can now define how long a cron job is allowed to run.
If it exceeds the configured limit, Kubernetes terminates the process automatically. Leave the value empty or set it to zero if no limit is required.
These controls won't matter during normal operation.
They matter when production doesn't go according to plan.
Instead of discovering days later that a scheduled task silently stopped running after a deployment or unexpected failure, your jobs now have built-in guardrails that help keep schedules moving without manual intervention.
Check out the process settings documentation.
Build applications faster with Railpack (Beta)#
Every deployment starts with a build.
The less time you spend configuring build systems, the faster your team ships.
Sevalla now supports Railpack (Beta), the successor to Nixpacks.
Railpack analyzes your repository, determines how your application should be built, and produces an optimized container image using BuildKit, all without requiring custom configuration.
It supports modern application stacks including:
- Node.js
- Python
- Go
- PHP
- Java
- Ruby
- .NET
- Deno
- Rust
- Elixir
If your application already defines a custom start command, Railpack respects it, making adoption straightforward without changing existing runtime behavior.
Railpack is available as an optional build strategy today while Nixpacks remains the default for new applications.
For teams evaluating new projects or modernizing existing deployments, it offers another way to reduce the amount of infrastructure work required before code reaches production.
Production should be simpler, not more complicated#
Two releases all point in the same direction.
- Keep scheduled workloads running without manual intervention.
- Reduce build configuration so new services get to production faster.
Less infrastructure work. More time building your product.
Transmission complete#
Two updates that reduce operational work before, during, and after deployment, helping production teams spend less time managing infrastructure and more time shipping software.
More improvements on the way.
Awaiting next transmission.
Link closed.