Skip to content
← Documentation
On this page

Apps

Everything you deploy lives in a project. This page covers what you can configure and how you run, pause, and observe your apps from the dashboard. For how to create and manage projects themselves, see Projects.

Two ways to deploy#

  • Apps — Deploy your own service from a container image (e.g. your API, frontend, worker). You set the image, how many instances, variables, CPU/memory, plus optional auto-scale or helpers. Ideal for services you build.
  • Managed services — Add a database, cache, or tool (e.g. PostgreSQL, Redis, Grafana) from Anyport's curated catalog. Anyport installs and maintains it for you — no charts to wrangle. See Managed services.

Apps live in your project; your apps connect to managed services running on the same cluster. Each app has a unique name within its project.

Apps (from images)#

What is an app?#

An app is your service, deployed from a container image with your settings: how many instances, which variables, how much CPU/memory, health checks, and optional auto-scale or helper containers. You create it in a project; Anyport deploys it to the right cluster and keeps status, logs, and metrics in one place.

Creating an app#

  1. Open a cluster and a project in Anyport.
  2. Go to Apps in that project and create a new one.
  3. Set a name, an image (e.g. myreg.io/myapp:v1), and how many instances you want.
  4. Optionally add variables, CPU/memory limits, ports, health checks (liveness and readiness), auto-scale (min/max instances based on load), helpers (extra containers alongside your app), and private registry credentials if your image is private.
  5. Submit. Anyport deploys the app; you see status, instances, and can view Logs and Metrics.

Key features#

FeatureWhat you get
Image & scaleRun any container image; set instance count or let auto-scale manage it.
VariablesSet variables per app; reference secrets and config.
CPU & memorySet CPU and memory limits so the cluster schedules and caps your app.
Health checksLiveness (is the process alive?), readiness (is it ready for traffic?), optional startup check. Anyport uses these to know when to send traffic and when to restart.
Auto-scaleMin/max instances and a target (e.g. CPU %). The cluster scales your app based on load.
HelpersAdd extra containers alongside your app (e.g. proxy, log shipper). Same lifecycle as your main app.
Pre-deploy commandAn optional command that runs with the incoming image before that version serves traffic. Migrations belong here: a non-zero exit stops the rollout and leaves the current version running. See Tasks.
PauseScale to zero when you're not using the app — saves cost without deleting. Resume when you need it.
RevisionsEach update creates a revision; view history and roll back when needed.
Logs & metricsLive logs and per-instance CPU/memory in the dashboard. See Logs & metrics.

Web apps and workers#

An app either serves requests or it does not. Serves web traffic is on by default when you create an app: it gets a port, a readiness check that dials that port, and a generated URL. Switch it off for a worker, a queue consumer or anything else that only makes outbound connections, and the app gets none of the three, so there is no probe that can never pass and no URL that answers nothing. The same switch is in the app's Domains settings for an app that already exists; any domain still pointing at the app has to be removed before it can become a worker. In an anyport.yaml a worker is kind: worker.

The start command#

A start command replaces what the image would otherwise run. How it runs depends on the image:

  • An image built by a buildpack runs the command in a shell behind the buildpack's launcher, which keeps the environment and PATH the buildpacks set up.
  • Any other image, from a Dockerfile build or a registry, runs the command in place of the image's entrypoint. A plain command such as /worker runs directly, which is what a distroless image with no shell needs; a command that uses the shell ($PORT, &&, a pipe) is run in /bin/sh -c.

Anyport reads which kind of image it is from the image itself on every rollout, so a repository that gains a Dockerfile changes with it.

Referencing other apps and services#

A variable's value can reference something else in the project instead of holding a copy of it, and the reference is resolved when the app is deployed:

ReferenceResolves to
${{ db.HOST }}, ${{ db.PASSWORD }}A key a managed service publishes. Credentials reach the container from a secret and are masked in the console.
${{ api.HOST }}, ${{ api.PORT }}, ${{ api.URL }}Another app's in-cluster address.
${{ api.PUBLIC_HOST }}, ${{ api.PUBLIC_URL }}Another app's public address: its custom domain if it has one, otherwise its generated hostname.
${{ cluster.DOMAIN }}The hostname the cluster's generated URLs sit under.
${{ NAME }}A project variable.

References can be mixed with text, as in https://web.${{ cluster.DOMAIN }}. A duplicated project resolves them against its own apps and services, so a copy points at itself rather than at the project it came from. Attaching a domain to an app redeploys the apps whose PUBLIC_* reference now resolves differently.

Variables Anyport sets#

Every app gets a few variables without you adding them. Read them the way you would on Railway or Vercel — for a release tag in your error tracker, a /version endpoint, or to find the sibling you need to call.

VariableValue
PORTThe port Anyport routes traffic to. Bind to it.
ANYPORT_PROJECT_NAMEThe project the app runs in.
ANYPORT_APP_NAMEThe app's name.
ANYPORT_PRIVATE_DOMAINThe hostname other apps in the project reach this one by.
ANYPORT_REPLICA_IDA name unique to this instance of the app.
ANYPORT_GIT_COMMIT_SHAThe commit the running image was built from.
ANYPORT_GIT_BRANCHThe branch that commit came from.
ANYPORT_GIT_REPO_OWNERThe GitHub account or organization that owns the repository.
ANYPORT_GIT_REPO_NAMEThe repository's name.
ANYPORT_GIT_COMMIT_MESSAGEThe commit's message.
ANYPORT_GIT_AUTHORWho authored the commit.

The ANYPORT_GIT_* variables are set for apps deployed from GitHub and describe whichever build is live, so they follow a rollback. An app deployed from an image you built elsewhere has none of them. A variable Anyport cannot fill in is left unset rather than set to an empty value, and a variable you define with the same name takes precedence.

Updating and rolling out#

Change the image, instances, variables, or any other setting and save. Anyport rolls out the change. You see status and instance states; if something fails, you can fix and redeploy from the same place. Revisions help you track what was deployed when.

While a rollout is in progress the app's overview groups its instances by revision: which revision is serving, which is arriving, and how many of each are ready. The previous revision keeps serving until the new one is ready, and if the new one cannot start, the card says why and offers to roll back to the one still serving.

Start order#

An app that reads from a managed service waits for that service before it starts. The dependency is worked out from what the app already references, so there is nothing to declare: an app that uses ${{ db.HOST }} does not roll out, and does not run its pre-deploy command, until db answers. A reference to a sibling app is a softer dependency, waited on for up to two minutes. This matters most when a whole project starts at once, as a duplicate, a preview or a one-click stack does. While an app waits, its status says what it is waiting for, and after fifteen minutes it asks for attention and names the dependency. Waiting never takes down a version that is already running.

Status and health#

The app detail view shows overall status (Running, Deploying, Paused, Error), the number of running instances, and any messages that explain what's happening. So you can debug without leaving Anyport.

When a container stops, the console says why in words: it ran out of memory (with the limit it went past), it exited with a code, it was evicted, it could not be scheduled, or its image could not be pulled. The same sentence appears on a failed build and a failed task run, so an out-of-memory build points at the build's memory setting rather than reading "Build job failed".

Managed services#

Beyond your own apps, most projects need a database, a cache, or a dashboard. Instead of writing charts, you add these from Anyport's curated catalog of managed services — Anyport installs and maintains each one, and your apps connect to it.

  • Add from the catalog — Pick a service (e.g. PostgreSQL, Redis, Grafana), give it a name, and add it. Sensible defaults are filled in for you.
  • Status & logs in one place — See whether a service is healthy and open its logs, just like your apps.
  • Connect from your apps — Use the service's in-cluster address, with credentials kept in secrets.
  • Advanced — Power users can still tune the underlying Helm values when they need to.

For the catalog and the full workflow, see Managed services.

When to use an app vs a managed service#

  • Use an app when deploying your own service (API, frontend, worker) and you want control over instances, variables, health checks, and auto-scale.
  • Use a managed service for off-the-shelf infrastructure (database, cache, tooling) you want Anyport to install and maintain.

One place for everything you run — your apps and the services they depend on. For projects (where your apps run), see Projects. For the service catalog, see Managed services. For logs and metrics, see Logs & metrics.

Next steps#