Skip to main content
Sevalla runs your applications and databases on Kubernetes clusters in the location you choose, serves static sites from Cloudflare’s edge, and stores files in Cloudflare R2. You work with companies, projects and services. Sevalla runs the clusters, builds, networking, TLS certificates and backups underneath.

​
Companies, projects and services

Everything you create on Sevalla belongs to a company:
  • A company owns services, people and billing. Each company has its own payment method, invoices and usage. You can belong to more than one company and switch between them in the dashboard. See Companies.
  • A project groups services inside a company, with its own spending view and its own members. A service belongs to one project at most. See Projects.
  • A service is anything that runs or stores something for you:
People get access to a whole company, to some projects, or to some services, with a role at that level. See Users and roles.

​
How an application runs

An application goes from source code to running processes in five steps. You push to a Git repository, or point Sevalla at an image in a container registry. Sevalla builds the image, keeps it in its own registry and rolls out the application's processes on a Kubernetes cluster in the location you chose, and Cloudflare's edge carries visitors' HTTPS traffic to the web process. You push to a Git repository, or point Sevalla at an image in a container registry. Sevalla builds the image, keeps it in its own registry and rolls out the application's processes on a Kubernetes cluster in the location you chose, and Cloudflare's edge carries visitors' HTTPS traffic to the web process.
  1. Source. You connect a repository on GitHub, GitLab or Bitbucket, use a public Git URL, or point Sevalla at a Docker image. See Git providers and Deploy a Docker image.
  2. Deployment. A deployment starts when you push to the application’s branch (with automatic deployments on), when you click Deploy now, when something calls the application’s deploy hook, or from the API, the CLI or an AI agent. See Deployments.
  3. Build. Sevalla builds a container image from the commit, on the cluster in the application’s location, with the application’s build strategy: Nixpacks (the default), Railpack, Buildpacks or a Dockerfile. Applications from a Docker image skip this step.
  4. Rollout. Sevalla stores the image in a private registry and updates every process of the application. Web processes and background workers run continuously, cron jobs run on their schedule, and jobs run once before or after the deployment. New instances start before the old ones stop (a process with a disk restarts instead), and if the rollout fails, the previous version keeps running.
  5. Traffic. Requests to the application’s sevalla.app address or its custom domains reach Cloudflare first. A worker that Sevalla runs on Cloudflare applies IP restrictions, caching and maintenance mode, then forwards the request to the web process in the application’s cluster. See How a request reaches an application.
Inside a location, an application reaches its databases and other applications over internal connections, which stay inside the cluster. A database also has an optional external connection for clients outside Sevalla. Static sites follow a shorter path: Sevalla builds the site from Git, uploads the files to Cloudflare R2, and serves them from Cloudflare’s edge. There is no server or location to choose. See Static sites.

​
Where your services run

Each location is a Kubernetes cluster on Google Cloud or Oracle Cloud Infrastructure (OCI). Sevalla is moving every company from Google Cloud to OCI: new companies start on OCI, and existing companies move in waves. A company’s applications and databases all run on the same cloud. See Migration to Oracle Cloud Infrastructure. Infrastructure describes the clusters, isolation, networking, storage and backups in detail, and what Sevalla manages for you.

​
Glossary