# 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](/docs/features/databases) - [Function (beta)](/docs/features/functions) Create one from your [**dashboard**](https://app.ownkube.io/dashboard). ## What you configure Every deployment has its own detail page in your [dashboard](https://app.ownkube.io/dashboard) with an **Overview**, **Settings**, and (for databases only) **Database** tab. Every field below is editable after creation. Saving triggers a rolling update. This page is the tour. For every field, its default, and its allowed range on each resource type, see the [Configuration reference](/docs/features/configuration-reference). ### Target - **Cluster**, any active cluster in your organization - **Environment**, [an environment](/docs/features/environments) like `Development` or `Production`, or no environment ### Container - **Registry**, one of your [connected registries](/docs/features/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. **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](/docs/guides/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](/docs/guides/environment-variables). ### 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 Scales replicas based on live CPU / memory usage. See [Autoscaling](/docs/features/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](/docs/features/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](/docs/features/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](/docs/features/functions) for runtimes, triggers, and limits. ## 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](/docs/features/databases).
## 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. **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: 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 - 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](/docs/guides/deploy-first-app) - [Databases](/docs/features/databases) --- **Don't see a feature you need?** Email [support@ownkube.io](mailto:support@ownkube.io?subject=Feature%20request). Ownkube is shaped by the teams using it and we ship what our users ask for.