Deployments
Web apps, background workers, one-off jobs. Pick a resource type, point at an image, deploy.
A deployment is a single workload running on a cluster. Ownkube supports five resource types. The same flow creates the cluster-bound ones, with different fields for each.
Web
HTTP service. Optional public hostname with automatic TLS.
Worker
Long-running background process. No public endpoint.
Job
Runs to completion and exits. Optional schedule for cron-style jobs.
Database
Managed PostgreSQL. See the Databases page for details.
Function (beta)
Serverless event handler triggered by HTTP or a cron schedule. Cluster-less. See the Functions page.
Create one from your dashboard.
What you configure
Every deployment lives at app.ownkube.io/dashboard/deployment/:deploymentId with an Overview, Settings, and (for databases only) Database tab. Every field below is editable after creation. Saving triggers a rolling update.
Target
- Cluster, any active cluster in your organization
- Environment, an environment like
DevelopmentorProduction, or no environment
Container
- Registry, one of your connected registries
- Repository, autocompletes from the registry (e.g.
your-org/api) - Tag, autocompletes from the repository (e.g.
v1.4.2) - Port, the port the container listens on, 1 to 65535
Public exposure (web / worker only)
Toggle Make this deployment public to get a generated hostname with automatic TLS.
Tip
Want to serve from a hostname you own? Add a CNAME record at your DNS provider pointing at the auto-allocated *.ownkube.app hostname. See Map a custom domain for the full walkthrough.
Environment variables
Any number of KEY=value pairs. Flip the Secret toggle on individual entries to mark them sensitive. They'll be masked in the UI and stored securely. See Environment variables.
Resources
Request and limit CPU and memory separately.
- Requests, the floor your container is guaranteed (e.g.
500mCPU,256Mimemory) - Limits, the ceiling it can't exceed
Leave them blank to start and tune later. Over-requesting is a common cause of unnecessary spend.
Autoscaling
Scales replicas based on live CPU / memory usage. See Autoscaling for the full field list.
Health probes
Three optional probes gate container lifecycle:
- Startup probe, how long a container has to boot before it's considered dead
- Liveness probe, restart the container if this fails
- Readiness probe, stop sending traffic to the container until this passes
Each probe takes a path, port, timeout, failure threshold, and initial delay. Most web apps only need a readiness probe on /health or /ready.
Replicas
For deployments without autoscaling, pick a fixed count (0 to 20). 0 pauses the deployment without deleting it.
Resource types in detail
Web
HTTP servers. Gets a public hostname if you toggle Public. Default replica count is 1; set higher for parallelism or turn on autoscaling.
Worker
Background services. No public endpoint. Use workers for queue consumers, scheduled background tasks, event processors, or anything that runs but doesn't serve HTTP.
Job
Runs a container to completion and exits. Useful for one-off migrations, backfills, or scheduled work. Once a job finishes successfully, it doesn't restart. For repeat schedules, configure the schedule when you create the job.
Database
A managed database deployment. See Databases for engines, versions, and connection details.
Function (beta)
A serverless event handler that runs without a cluster. Functions attach to an AWS account and region rather than a cluster, build from a GitHub repository, and fire on an HTTP request or a cron schedule. See Functions for runtimes, triggers, and limits.
The deployment detail page
App platform version
Every app, worker, and job runs on the app platform version: the runtime Ownkube ships to power your deployments. When we publish a newer version with improvements, the Overview tab shows an Upgrade control.
Upgrades are forward-only. You can move to a newer version, but not back to an older one. The selector hides older versions and a hint explains why.
Tip
Keep up to date. Staying on the latest app platform version is how you get new features and runtime improvements as they ship. We'll let you know in-app when an upgrade is available and what changed. Upgrades are designed so they don't affect deployment quality.
Deleting a deployment
Click Delete on the deployment detail page. Ownkube:
- Removes the running workload from the cluster
- Releases the public hostname, if any
- Soft-deletes the database row (kept for audit history)
Once a deployment is deleted, its allocated public hostname is released and can be reused.
Limits and constraints
- Deployments can only target active clusters
- Name must be unique within the cluster + environment pair
- Public hostnames can only be allocated for web deployments (and workers that opt in)
- Replicas capped at 20 without autoscaling; autoscaling goes up to 100
- Image tags should be pinned.
latestworks but makes each deploy harder to trace back to a specific build.
Deploy your first app
End-to-end walkthrough for a first deployment.
Databases
Managed PostgreSQL and how credentials are auto-injected.
Don't see a feature you need? Email support@ownkube.io. Ownkube is shaped by the teams using it and we ship what our users ask for.