Skip to main content
This checklist covers the Sevalla settings that most affect uptime and recovery. Run through it once the application deploys successfully on its sevalla.app domain, before you point real users at it.

​
Build and start

  • The last deployment’s status is Deployed and its build log has no warnings you don’t understand.
  • The build path points at the application’s folder, if it isn’t at the repository root (common in monorepos).
  • The web process’s start command runs a long-lived server, and the server listens on the port in the PORT environment variable. See Processes and Web process port.
  • The language version is pinned in the repository (for example engines.node in package.json or .python-version), so a builder update doesn’t change it. See your build strategy’s page.

​
Configuration and secrets

  • Every secret and setting is an environment variable in Sevalla, not a committed .env file.
  • Variables the build needs (for example public variables your framework inlines into the bundle) are available during the build, not only at runtime, and were set before the last build.

​
Health checks

  • The web process has a readiness probe on a real endpoint (for example /healthz), so instances get traffic only when they can serve it, and deployments switch over without errors.
  • If the application can hang without crashing, the web process also has a liveness probe, so Sevalla restarts stuck instances.
  • The health check endpoint doesn’t fail when a third-party service is slow, so one outage elsewhere doesn’t restart every instance.
Probes are under Health checks when you update the web process. See Health checks.

​
Size and scaling

  • The process size comes from real load, checked on the Analytics tab, not a guess.
  • The web process runs at least 2 instances, so one instance restarting doesn’t take the application down.
  • Horizontal autoscaling is on for traffic that varies, with a maximum high enough for a spike. See Scaling.
  • Hibernation is off, unless visitors can wait for the first response after a quiet period: the application wakes usually within 90 seconds, and Sevalla holds that first request for up to about 3 minutes.

​
Storage

  • The application writes nothing it needs to keep to the local filesystem: it’s lost on every deployment and restart.
  • Uploads and generated files go to object storage, or to a disk if they must be local. Object storage keeps processes free to run more than one instance.

​
Domain and SSL

  • The web process isn’t on the H1 size: custom domains need a larger one. See Instance sizes.
  • The production domain is added on the Domains tab, its DNS records are in place, and its status is active with an SSL certificate. See Custom domains.
  • If your DNS has CAA records, they allow the certificate authority Sevalla uses. See Troubleshoot custom domains.
  • If the application serves cacheable static assets, consider turning on the CDN and edge caching: neither is on by default.

​
Database

  • The database runs in the same location as the application, and the application connects through an internal connection, not over the internet.
  • You’ve taken a manual backup and know how to restore it before you need to. See Backups.

​
Deployments

  • Automatic deployments are on or off on purpose, on the right branch.
  • Changes reach production through a staging application first, for example with a pipeline.
  • Database migrations run as a Job process with the start policy Before deployment, not in the web process’s start command, so a failed migration stops the deployment instead of crash-looping the web process.
  • You know how to roll back to the previous deployment.

​
Alerts

  • Everyone who should react to a failed deployment has Failed deployment emails on, under My account > Notifications. They’re on by default. See My account.
  • A usage alert warns you before spending passes your budget.
  • You’re subscribed to Sevalla’s status page.