Sevalla Changelog #0092 Production Gets Simpler

Establishing connection…

Signal detected.

Link established.

Baud here with a 56k Sevalla changelog transmission.

Three updates shipped over the last two weeks, all focused on removing operational friction for teams running production workloads. One helps stop abusive traffic before it reaches your application. Another makes scheduled jobs more resilient when things go wrong. The third speeds up the path from source code to a running application with a new generation of build technology.

Quick links to the updates:

• Stop abusive traffic before it reaches your application
• Cron jobs that recover instead of getting stuck
• Build applications faster with Railpack (Beta)

---

Stop abusive traffic before it reaches your application#

Production traffic is unpredictable. Whether it's an aggressive bot, a misconfigured client, or an attempted denial-of-service attack, you shouldn't have to discover the problem only after your application is overwhelmed.

Applications, Static Sites, and Load Balancers now include built-in rate limiting, enforced by Cloudflare at the edge before requests ever reach your service.

You can choose how Sevalla responds when a client exceeds the configured limit:

• Challenge to require a Cloudflare-managed verification before traffic resumes.
• Throttle to temporarily reject excess requests while abusive traffic continues.
• Ban to block the offending client for five minutes.

Because limits are tracked per IP address, domain, and Cloudflare edge location, legitimate traffic continues flowing while abusive clients are isolated. You're protecting against individual bad actors instead of artificially capping your entire application.

For production teams, this means one less security service to stitch together and one less operational concern to manage outside the platform.

Rate limiting is available from the new Networking tab for Applications, Static Sites, and Load Balancers. Static Sites also receive a dedicated Networking section, with CDN cache purge controls now located there for easier management.

See the docs for applications, static sites, and load balancers.

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.

Transmission complete#

Three updates that reduce operational work before, during, and after deployment — edge rate limiting to stop abusive traffic, smarter cron scheduling to keep jobs running, and Railpack builds to get new services to production faster.

More improvements on the way.

Awaiting next transmission.

Link closed.