Skip to content
Ownkube

Deployments

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

Section titled “What you configure”

Every deployment has its own detail page in your dashboard with an Overview, Settings, and (for databases only) Database tab. Every field below is editable after creation. Saving triggers a rolling update.

Target

Section titled “Target”
  • Cluster, any active cluster in your organization
  • Environment, an environment like Development or Production, or no environment

Container

Section titled “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)

Section titled “Public exposure (web / worker only)”

Toggle Make this deployment public to get a generated hostname with automatic TLS.

Environment variables

Section titled “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

Section titled “Resources”

Request and limit CPU and memory separately.

  • Requests, the floor your container is guaranteed (e.g. 500m CPU, 256Mi memory)
  • 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

Section titled “Autoscaling”

Scales replicas based on live CPU / memory usage. See Autoscaling for the full field list.

Health probes

Section titled “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

Section titled “Replicas”

For deployments without autoscaling, pick a fixed count (0 to 20). 0 pauses the deployment without deleting it.

Resource types in detail

Section titled “Resource types in detail”

Web

Section titled “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

Section titled “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

Section titled “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

Section titled “Database”

A managed database deployment. See Databases for engines, versions, and connection details.

Function (beta)

Section titled “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

Section titled “The deployment detail page”
Overview

Live status (healthy, syncing, degraded), public hostname (if applicable), current image and tag, replica count, and the current app platform version with an Upgrade control if a newer version is available.

Settings

Every knob described above, editable inline: container image, port, public toggle, env vars, resources, autoscaling, health probes. Saving any change triggers a rolling update.

Database (databases only)

Connection details (host, port, database, username, password), copy-friendly connection string, and backup status. See Databases.

App platform version

Section titled “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.

Deleting a deployment

Section titled “Deleting a deployment”

Click Delete on the deployment detail page. Ownkube:

  1. Removes the running workload from the cluster
  2. Releases the public hostname, if any
  3. 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

Section titled “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. latest works 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.