Deployments

A deployment is how you run your application on Mengi Cloud. You point Mengi at a Docker image (or a Helm chart), choose where it runs and how much CPU/memory it gets, and Mengi provisions it on a Kubernetes cluster — with a public HTTPS URL, persistent storage and environment variables wired up for you.

You describe the app in the dashboard (or via the API) and Mengi continuously keeps the cluster matching that description — you never have to touch Kubernetes or write YAML.

What Mengi creates for a deployment

When a deployment reaches running, Mengi has created the following on the cluster:

Resource	Purpose
A Deployment (pods)	Runs your container image with the CPU/memory and replica count you chose
A Service	Stable in-cluster network address for your pods
An Ingress + TLS certificate	Public HTTPS URL, with a TLS certificate issued and renewed automatically
A PersistentVolumeClaim	Only if you added persistent storage
A ConfigMap / Secret	Holds your environment variables (secret values stay encrypted)

You can delete everything at any time from the dashboard — deleting a deployment removes all of these resources from the cluster.

Part 1 — Create a deployment

Start from New deployment in the dashboard. The wizard has four steps.

1. Choose where it runs

A shared region — the quickest option. Pick a geographic region (e.g. Europe, North America, Asia-Pacific) and Mengi runs your app on a managed, multi-tenant cluster. No cluster to create or maintain; you only pay for the resources your deployment uses.
An existing cluster — deploy onto a cluster you already created (including a dedicated or BYOC cluster — see Bring Your Own Cloud).

If you choose a shared region and don’t have infrastructure yet, Mengi sets it up as part of creating the deployment.

2. Choose the service type

Docker — deploy any container image from a public or private registry (e.g. nginx:latest, ghcr.io/owner/app:1.4.2).
Helm — deploy a Helm chart from a chart repository (repo URL + chart name + version), with optional custom values.yaml. Mengi can inspect the chart so you can see its default values before deploying.

3. Configure the deployment

For a Docker deployment:

Image — enter the image reference. Mengi analyses the image (see Image analysis below) and pre-fills the container port, suggested environment variables and volumes.
Container port — the port your app listens on (defaults to a common value; adjust if analysis didn’t detect it).

For a Helm deployment: provide the chart repo, name and version, and any values overrides.

For both types you then set:

Name — a recognisable name for the deployment.
Resources — CPU and memory, via presets (Small / Medium / Large / X-Large) or a custom value. CPU runs from a fraction of a vCPU up to several vCPUs; memory from 128 MB up to several GB.
Replicas — how many copies of your app to run (default 1). More replicas = higher availability and throughput.
Environment variables (optional) — add key/value pairs. Each value is either plain text or a secret reference (see Environment variables and secrets). Image analysis flags variables an image expects.
Persistent storage (optional) — add one or more volumes, each with a mount path and a size in GB, for data that must survive restarts.
Image update strategy (Docker only, optional) — let Mengi automatically roll out new image versions as they’re published. Choose a strategy (semver, newest-build, digest, or alphabetical) and, for semver, a constraint such as ~1.0 or ^2.0. Leave it disabled to update only when you change the image yourself.

4. Confirm

If creating new infrastructure requires it, you’ll confirm your payment method, then create the deployment. It moves through pending → provisioning → running. Once running, the dashboard shows its public URL.

Image analysis (what Mengi detects)

When you enter a Docker image, Mengi analyses it (and caches the result) and suggests sensible defaults so you don’t have to hunt through the image’s documentation. It surfaces:

Ports the image exposes.
Environment variables the image expects, marked required or optional with a short description.
Volumes / mount points the image uses for data.
Backing services it likely needs (PostgreSQL, Redis, MongoDB, …).
Health-check and best-practice suggestions, and a 12-factor readiness view.

These are suggestions — you can override any of them before creating the deployment.

Environment variables and secrets

Every deployment can take environment variables. Each one is either:

a plain value you type in, or
a secret reference — the value comes from a secret instead of being stored in the deployment’s configuration.

Use secrets for anything sensitive — passwords, API keys, tokens. When you add an environment variable you can:

Pick an existing secret — secrets you created on the Secrets page are offered in a dropdown.
Create one inline — add a new secret right from the environment-variable row, without leaving the wizard.

Secret values are injected into your container at runtime and never appear in the deployment configuration or the dashboard. This is also how you connect a managed database: the database publishes its credentials as a secret, and you reference that secret here so the password reaches your app without ever being copied around.

Accessing your app

URL — every deployment with a web port gets a public address like https://<id>.apps.mengi.cloud, shown on the deployment once it’s running.
HTTPS — TLS certificates for *.apps.mengi.cloud are issued and renewed automatically. There’s nothing to configure.
Custom domains — serve your app on your own domain by picking it in the deployment’s Custom Domain settings (available in the wizard and on an existing deployment). Requires a dedicated cluster and a connected DNS provider — see Custom Domains.

Managing a deployment

From a deployment’s page you can:

Watch status & health — Mengi tracks the live sync/health state, so you can see when a rollout is in progress, healthy, or degraded.
View logs and metrics — application logs and CPU/memory metrics are collected per deployment.
Update it — change the image tag, environment variables, resources or replica count. Mengi regenerates the config and performs a rolling update (no downtime for multi-replica apps).
Scale — change the replica count up or down at any time.
Promote to another cluster — copy a deployment’s configuration to a different cluster (e.g. dev → production). This recreates the app on the target cluster; it does not migrate data in persistent volumes.
Delete it — removes the deployment and all its Kubernetes resources.
Import existing workloads — point Mengi at a cluster and it can discover and adopt Deployments/Helm releases already running there, so you can manage them through Mengi.

Shared vs. dedicated clusters

Shared — multi-tenant, Mengi-managed clusters. Cheapest and fastest to start; you pay only for your deployment’s resources. Ideal for prototypes, staging and smaller production apps.
Dedicated / BYOC — your own single-tenant cluster (on Mengi’s infrastructure or your own cloud account). Full isolation and control; deploy to it just like any other cluster by picking it in step 1.

Good to know

Private images are supported; store the registry credentials so Mengi can pull them.
Rollouts are declarative — every change you make is applied automatically, so the running app always matches your declared configuration.
A deployment inherits its provider and region from the cluster it runs on.