Web app
Deployments
A deployment is a single workload running on Ownkube. There are five resource types. The same create flow makes all of them, with different fields for each, and every one lives in an environment and a project.
Worker
A long-running background process with no public endpoint: queue consumers, bots, event processors.
Scheduled job
Runs a container to completion, once or on a cron schedule, with a run history. See Scheduled jobs.
Database
Managed Postgres 17 or 18, private by default, with backups and point-in-time recovery. See Postgres.
Cache
Managed Valkey, Redis-compatible and in memory. See Valkey cache.
Create one from the dashboard with New, or with ⌘ K and Deployment. The walkthrough is on Create a deployment.
Where a deployment comes from
Section titled “Where a deployment comes from”A web app, worker or job runs a container image. Ownkube gets that image one of two ways:
- Build from GitHub or GitLab. Connect a repository and branch. Ownkube builds on every push, with your Dockerfile or with the automatic build. See Builds and source.
- Use an existing image. Give an image reference and tag from a public registry, such as
ghcr.io/owner/app:1.2.0.
Databases and caches run images Ownkube ships, so there is nothing to build.
What you configure
Section titled “What you configure”Every field is editable after creation from the deployment’s Settings tab. Saving creates a new revision and rolls it out.
| Area | What it covers | Read more |
|---|---|---|
| Source | Repository and branch, or image and tag | Builds and source |
| Port and hostname | The port the container listens on; a public hostname with TLS | Public hostnames and TLS |
| Variables | Plain and secret KEY=value pairs, plus environment-wide shared variables | Variables |
| Resources | CPU and memory, metered or a flat reserved box | Configuration reference |
| Scaling | A fixed replica count, or autoscaling on CPU and memory | Autoscaling |
| Sleep | Scale an idle web app to zero and wake it on the next request | Sleep and wake |
| Health checks | Startup, liveness and readiness probes | Health checks |
| Region | Asia (Mumbai) or Europe (Germany), set at creation | Regions |
The full list of fields, defaults and ranges is the Configuration reference.
The deployment page
Section titled “The deployment page”Each deployment has its own page with tabs for what it is. A web app or worker shows Overview, Variables, Logs, Activity, Components, Security, Builder and Settings. A job swaps in a Runs tab. A database or cache has Overview, Data, Logs, Activity and Settings. The basics has the full matrix.
The Overview tab shows live status, the public hostname, the current image or commit, replica count, CPU and memory charts, the Alerts card, and the app platform version with an Upgrade control when a newer version is available.
How a rollout works
Section titled “How a rollout works”Every saved change rolls out gradually. New containers start, pass their health checks, and only then take traffic while the old ones stop. There is no separate deploy button. A rollout that cannot become healthy leaves the previous revision serving, and the Activity tab shows what changed with a one-click rollback.
Status during a rollout moves through Syncing to Healthy, or to Degraded if a container keeps failing. See Observability for every status.
App platform version
Section titled “App platform version”Web apps, workers and jobs run on the app platform version, the runtime Ownkube ships underneath your container. When a newer version is published, the Overview tab shows an Upgrade control. Upgrades are forward-only and designed not to affect a running deployment. See platform version.
Deleting a deployment
Section titled “Deleting a deployment”Delete lives at the bottom of the Settings tab and asks you to type the deployment’s name. Deleting stops the workload, releases its hostname, and for a database or cache removes the data. Owners and admins can delete; see Organizations and roles.
Limits
Section titled “Limits”- A deployment’s name must be unique within its environment.
- Fixed replicas go up to 20; autoscaling up to 100.
- Public hostnames are allocated to web apps. Workers and jobs stay private.
- Pin image tags.
latestworks, but every deploy is then harder to trace to a build.
Create a deployment The create flow, every field explained.
Configuration reference Defaults and ranges for every field, by resource type.
Scheduled jobs One-off and cron jobs with a run history.