Skip to main content
Sevalla runs applications and databases on Kubernetes clusters, one per location, on Oracle Cloud Infrastructure (OCI) or Google Cloud. Cloudflare sits in front of every application, static site and load balancer, and Cloudflare R2 stores static site files and object storage. Sevalla operates all of it: you deploy code and choose sizes, never servers.

​
Clouds and clusters

Each location is one Kubernetes cluster: Oracle Kubernetes Engine (OKE) on OCI, or Google Kubernetes Engine (GKE) on Google Cloud. All of a company’s applications and databases run on the same cloud. Sevalla is moving every company from Google Cloud to OCI. New companies start on OCI, existing companies move in waves, and static site builds already run on OCI for everyone. Static sites, buckets and load balancers don’t move: they run on Cloudflare. Where the two clouds differ, this page says so. Migration to Oracle Cloud Infrastructure covers the schedule and what changes for you.

​
Applications

​
Builds and images

Every deployment from Git builds a new container image. The build runs as a sandboxed job on the cluster in the application’s location, with the application’s build strategy (Nixpacks, Railpack, Buildpacks or Dockerfile). On OCI, builds run on nodes reserved for builds, apart from running applications. By default, a build that runs longer than 30 minutes fails. Sevalla stores each image in a private registry on the application’s cloud. Each image is tagged with its deployment, which is what lets Sevalla roll back and lets pipelines promote an image to another application without rebuilding it. An application from a Docker image skips the build: the cluster pulls the image from its registry on every deployment.

​
Processes and instances

Each application gets its own Kubernetes namespace, and each of its processes runs there as its own set of containers: Each instance of a process is one container with the CPU and memory of the process’s instance size. During a rollout, Kubernetes starts new instances before it stops the old ones. If the new version isn’t ready within 20 minutes, the deployment fails and the previous version, which kept serving traffic, stays live. A process with a disk runs one instance and is restarted instead (the old instance stops before the new one starts), so its deployments have a short interruption.

​
How a request reaches an application

A visitor's request passes through Cloudflare's edge and Sevalla's edge worker, which applies IP restrictions, the HTTPS redirect and maintenance mode, and answers from the edge cache when it can. The rest goes to the load balancer and ingress in your application's location, which routes it by domain to an instance of the web process, and instances reach the database in the same cluster over an internal connection. A visitor's request passes through Cloudflare's edge and Sevalla's edge worker, which applies IP restrictions, the HTTPS redirect and maintenance mode, and answers from the edge cache when it can. The rest goes to the load balancer and ingress in your application's location, which routes it by domain to an instance of the web process, and instances reach the database in the same cluster over an internal connection.
  1. Cloudflare. The application’s sevalla.app address and its custom domains point to Cloudflare. Cloudflare ends the TLS connection with a certificate it issues for each domain, and applies its DDoS protection. See DDoS protection.
  2. Sevalla’s application worker. A Cloudflare Worker that Sevalla runs at the edge reads the domain’s settings and, in this order: blocks IP addresses outside the application’s IP restrictions with 403, redirects HTTP to HTTPS with 301, answers with 503 and Retry-After: 300 while maintenance mode is on, and serves the response from the edge cache when CDN or edge caching has a copy. If the application is hibernating, the worker holds the request while the application wakes up, for up to about 3 minutes.
  3. The cluster. The worker forwards the request to the cluster in the application’s location, where Sevalla’s ingress matches the domain to the application’s web process.
  4. The web process. Kubernetes spreads requests across the web process’s instances. The instance answers, often after querying a database over an internal connection.
  5. The response goes back the same way. The worker stores it at the edge if caching applies, and adds an Access-Control-Allow-Origin: * header when the application didn’t set one.
Request headers lists the headers Cloudflare and Sevalla add on the way.

​
Private networking

Services in the same location talk over the cluster’s private network. Each web process, background worker and database has a private hostname inside the cluster. By default, a namespace doesn’t accept traffic from other namespaces: an internal connection opens the path between an application and a database, or between two applications. Internal connections only work within one location. A TCP proxy gives a process a public hostname and port for protocols other than HTTP. It goes through Sevalla’s TCP proxy in the location, not through Cloudflare.

​
Outbound traffic

  • On OCI, each location sends outbound traffic from one fixed IP address.
  • On Google Cloud, outbound traffic comes from any of Google Cloud’s published IP ranges for the region.
The application’s Networking tab lists its egress IP addresses, as described in Egress IP addresses. Outbound connections to the cloud’s instance metadata address and to email ports are blocked: TCP ports 25, 465 and 587 on both clouds, and also 2525 on OCI. To send email, use your email provider’s HTTP API.

​
Databases

A database runs with a persistent volume in a Kubernetes cluster in your location, where applications reach it over an internal connection by its private hostname. Clients elsewhere connect through a TCP proxy at <db>.ext.sevalla.app, behind an IP allowlist, and Sevalla backs it up daily, keeping the backups or sending them to your own S3 bucket. A database runs with a persistent volume in a Kubernetes cluster in your location, where applications reach it over an internal connection by its private hostname. Clients elsewhere connect through a TCP proxy at <db>.ext.sevalla.app, behind an IP allowlist, and Sevalla backs it up daily, keeping the backups or sending them to your own S3 bucket. Each database runs in its own namespace on the cluster of its location, with its data on a persistent volume in that location. Sevalla runs and configures the engine for you on both clouds. The engine versions on offer differ between Google Cloud and OCI locations: see Engines and versions. Applications reach a database over an internal connection. Clients outside Sevalla use its external connection: a hostname under ext.sevalla.app with its own port, through Sevalla’s TCP proxy in the location. That traffic doesn’t pass through Cloudflare, and the database’s IP restrictions apply at the proxy. The legacy external connection hostnames were turned off on Oct 15, 2026. Backups depend on the cloud:
  • On Google Cloud, Sevalla takes a daily snapshot of the database’s volume and keeps it for 7 days. You can also take manual backups.
  • On OCI, Sevalla writes compressed dumps of the database (for example .sql.gz) on a schedule to the backup targets you add: Sevalla object storage buckets or your own S3-compatible storage. A database on OCI without a backup target has no backups.
Backups covers schedules, restores and limits.

​
Static sites

On a push, or when you click Deploy now, Sevalla builds the site in a build container, uploads the publish directory to Cloudflare R2, switches your domains to the new deployment and purges the cache. Requests go to Sevalla's edge worker, which applies _redirects, _headers, pretty URLs and the 404 page, and answers from the edge cache or fetches the file from R2. On a push, or when you click Deploy now, Sevalla builds the site in a build container, uploads the publish directory to Cloudflare R2, switches your domains to the new deployment and purges the cache. Requests go to Sevalla's edge worker, which applies _redirects, _headers, pretty URLs and the 404 page, and answers from the edge cache or fetches the file from R2. Sevalla builds every static site in a sandboxed container on its build cluster in Oracle Cloud’s US East (Ashburn) data center, uploads the files that changed to Cloudflare R2, and switches the site’s domains to the new deployment in one step. A Cloudflare Worker that Sevalla runs at the edge then serves each request from Cloudflare’s cache or from R2. A static site has no server, no location and no instances to scale. How static sites work describes each step.

​
Object storage

A bucket is stored in Cloudflare R2. Your app, the AWS CLI or an SDK reach it through the S3 API endpoint with access keys, Sevalla's dashboard and API create buckets and upload files, and with public access on, browsers get its files from <bucket>.sevalla.storage through Cloudflare's CDN. A bucket is stored in Cloudflare R2. Your app, the AWS CLI or an SDK reach it through the S3 API endpoint with access keys, Sevalla's dashboard and API create buckets and upload files, and with public access on, browsers get its files from <bucket>.sevalla.storage through Cloudflare's CDN. Each bucket is a Cloudflare R2 bucket in Sevalla’s Cloudflare account, with its own access keys that only work for that bucket.
  • S3 API. Applications and tools connect to the bucket’s R2 endpoint with any S3-compatible client. See Connect with the S3 API.
  • Dashboard uploads. Files you upload in the dashboard go through Sevalla’s API to the bucket, up to 300 MB per file.
  • Public access. When you turn it on, the bucket gets a public domain, <bucket>.sevalla.storage, served through Cloudflare’s CDN.

​
Logs and metrics

  • Access logs come from Cloudflare: every request through the edge is logged, then attributed to its service.
  • Runtime logs are collected from your processes’ output (stdout and stderr).
  • Metrics such as CPU, memory, storage and instance counts come from the cluster.
Sevalla stores logs in its own log store, which feeds the Logs and Analytics tabs. See Logs and Analytics.

​
Isolation

  • One namespace per service. Every application and every database has its own Kubernetes namespace, and namespaces don’t accept traffic from each other unless an internal connection allows it.
  • Sandboxed containers. Application instances and builds run in sandboxed containers that isolate each container in its own user namespace, without access to the Kubernetes API.
  • Resource limits. Each instance gets the CPU and memory of its instance size, with up to 20 GB of ephemeral storage that doesn’t survive a restart.
  • Edge protection. For HTTP traffic, Cloudflare handles TLS and absorbs DDoS attacks before requests reach a cluster. TCP proxies and database external connections don’t go through Cloudflare.
See Security for certifications, encryption and access controls.

​
What Sevalla manages and what you manage

Shared responsibility covers security duties in detail.

​
Where your data is

Applications, their disks and databases store their data in the location you choose. Data leaves that location only in these cases:
  • Cached copies. With CDN or edge caching on, and for every static site, Cloudflare keeps copies of responses in its edge locations near your visitors.
  • Static site files and object storage live in Cloudflare R2.
  • Logs. Cloudflare processes every request to your services, and Sevalla keeps access and runtime logs for the Logs and Analytics tabs.
  • Database backups on OCI go to the backup targets you add.
  • Support conversations. Anything you share in a support chat is stored by Sevalla’s chat provider.