Skip to content
Ownkube

Deploy your first app

This guide takes you from a container image to a live URL. You should already have an Ownkube account, a connected AWS account, a cluster, and a registry.

Open the create-deployment flow from your dashboard to follow along.

Before you start

Section titled “Before you start”
  • A cluster in the active state
  • A connected registry or GitHub repository with at least one image built and pushed (Amazon ECR, a build from your GitHub repository, or a public image)
  • The image tag you want to deploy (e.g. v1.4.2, a git SHA, or latest)
  • The port your app listens on

Create the deployment

Section titled “Create the deployment”

  1. Open the create-deployment page

    Open the create-deployment flow from your dashboard.

  2. Pick a resource type

    • Web, HTTP service with an optional public hostname
    • Worker, long-running background process, no HTTP endpoint
    • Job, runs to completion; add a cron schedule for repeat runs
    • Database, managed PostgreSQL (see Databases)

    Pick Web for this walkthrough.

  3. Pick a target

    • Cluster, any active cluster in your organization
    • Environment, Development or Production by default, or create a new one inline. See Environments.

  4. Configure the container

    • Registry, one of your connected registries
    • Repository, autocompletes from the registry (e.g. your-org/api)
    • Tag, autocompletes from the repository. Pin a specific tag like v1.4.2 instead of latest. It makes every deploy traceable to a known image.
    • Port, the port your app listens on (e.g. 3000)

  5. Add environment variables

    Any number of KEY=value pairs. Flip the Secret toggle on individual entries to mask sensitive values in the UI. See Environment variables for the full reference.

  6. Toggle public exposure (web only)

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

  7. (Optional) Set resources and health probes

    You can leave resources blank to start. For health probes, a readiness probe pointed at /health or /ready is typically enough for a web app. See Deployments for the full field list.

  8. Click Create deployment

    The detail page opens with live status. You’ll see image pull, startup, and health-check progression in real time.

Verify it’s running

Section titled “Verify it’s running”

When the deployment reaches healthy on the Overview tab:

  1. Click the generated hostname (under Public hostname if you toggled public on)
  2. You should see your app

If the status is degraded, a health probe is failing. Open the Overview tab and look at the live event stream. The failure reason is surfaced there. Common causes:

  • App listens on a different port than the one you configured
  • Health-check path returns a non-2xx status
  • Container crashes on startup. Check that the image tag is correct and the required env vars are set.

What happens on subsequent deploys

Section titled “What happens on subsequent deploys”

Push a new image to your registry, then come back to your dashboard, click your deployment, go to Settings, update the Tag field, and Save. The platform rolls a new version out. New containers come up, pass health checks, and take traffic while the old ones drain.

No separate “deploy button”, no pipeline config to maintain.

Environment variables Secrets, plain-text config, and auto-injected database credentials.
Databases Attach managed Postgres with auto-injected credentials.