Skip to content
Ownkube

Deploy your first app

This guide takes you from a repo or a container image to a live URL on Ownkube Compute, the fully managed path with no cloud account and no cluster to provision. It expands on the Quickstart with every field explained, so you know what each one does before you fill it in.

You need an Ownkube account and either a GitHub or GitLab repository Ownkube can build from, or a container image (a public one, or one in a connected registry). That’s it. Open the create-deployment flow from your dashboard to follow along.

Before you start

Section titled “Before you start”
  • A source: a GitHub or GitLab repository to build from, an image in a connected registry, or a public image reference
  • The image tag you want to deploy (e.g. v1.4.2, a git SHA, or latest), if you’re deploying an existing image
  • 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 an environment

    Choose an environment like Development or Production, or create one inline. Environments keep dev and prod config separate; a deployment belongs to one of them.

  4. Configure the source

    • Build from a repo: pick the GitHub or GitLab repository and branch. Ownkube builds the image (with or without a Dockerfile) and ships it.
    • Use an existing image: pick the Registry, Repository (autocompletes, e.g. your-org/api), and Tag. 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 the build (if building from source), 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 commit (for source deployments) or a new image tag, then come back to your dashboard, click your deployment, go to Settings, update the source or 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.