Service containers
A service container is the thing that actually gets deployed and runs on SdV Cloud — a single application, built from your repository, kept alive and reachable. Every deployment, every log line, and every scaling decision happens in the context of one service container.
Where it comes from
Section titled “Where it comes from”A service container is built from a Git repository — currently GitLab, at a branch you choose. Every deployment rebuilds it from the latest commit on that branch, using either a Dockerfile or, once available, a buildpack, so it doesn’t have to guess how to package your application.
What kind of service it is
Section titled “What kind of service it is”A service container is one of three kinds, matching the shape of work it does:
| Kind | Runs |
|---|---|
| HTTP service | Handles incoming web requests and is reachable at a URL |
| Worker | Runs continuously in the background, without accepting requests |
| Scheduled job | Runs on a recurring schedule, not continuously |
Right now, only HTTP services are available — the others are on the roadmap.
What it’s configured with
Section titled “What it’s configured with”Beyond its source and kind, a service container’s configuration covers everything it needs to run:
- Resources — how much CPU and memory each running copy gets, either from a preset or a custom amount.
- Environment — the environment variables your application reads at runtime.
- Storage — persistent volumes your application can read and write to across restarts.
- Autoscaling and hibernation — how many copies run under load, and whether it scales to zero on a schedule. See The deployment lifecycle for how this relates to what’s actually running.
- Security — access restrictions like an IP allowlist or basic authentication in front of it.
A service container isn’t fully usable until it has a branch to deploy from — everything else has a sensible default.
Where it lives
Section titled “Where it lives”A service container always belongs to one project, and through it, one organization. Its name, logs, and running state are scoped to that project — moving work between projects means creating a new service container, not relocating an existing one.