Skip to content

Documentation

Everything, as it actually works.

Connect a cluster, deploy from a repository, and run what you shipped. Every page describes the product as it is today.

Start here: cluster to serving in two commands →

Getting started

Install the CLI, connect a cluster or have Anyport run one, get an app serving on a real URL, and find what to check when a step does not work.

Deploying

Ship from a GitHub repository or an image you already publish, put a domain in front of it, and give every pull request its own environment.

Organization

Invite your team, decide who can see and change each cluster and project, and choose where deploy and health events are sent.

Tools

Do the same things from a terminal, or hand your organization to an AI agent.

Concepts

How Anyport is put together: projects, services, the gateway, and what the agent does in your cluster.

Inventory

What Anyport does today

Every line ships today and works on every cluster you connect. Nothing here is planned or merged but unreleased; a line is removed the day its feature goes.

Deploying

  • Connect a GitHub repository once and every push builds and rolls out. There is no pipeline to write and no runner to keep alive.
  • Or deploy an image you already publish, from any registry, public or private.
  • Builds run on your own cluster, from your Dockerfile. They are never billed by the minute, because they never run on our hardware.
  • Every deploy is a numbered revision, and rolling back to any of them is one click.
  • Builds and rollouts share one timeline, showing what shipped, the commit it came from, and whether a push or a person started it.
  • A deploy tells you what it changed, in the words the console uses: the image, the variables, the resources, the domains. Not two YAML documents to compare by eye.
  • Open a pull request and it gets the whole project on its own URL, torn down when the pull request closes.

Scheduled and one-off work

  • Run a container on a cron schedule for the work nobody should have to remember: nightly reports, cleanups, retries, expiries.
  • A task inherits an app's image, variables and secrets, so most tasks are that app with a different command.
  • Run any task by hand and watch its logs while it runs. Every run is kept in the task's history with its outcome, what triggered it and the reason it failed, so the one that failed at 3am is still there in the morning.
  • Give an app a pre-deploy command and it runs with the incoming image before that version serves anything. Migrations belong here: a non-zero exit stops the rollout and leaves the previous version up.
  • Per task: a timeout, a retry count, and what to do when the last run is still going. Overlapping runs are refused by default.

Traffic and domains

  • Every app is reachable on a generated URL the moment it deploys.
  • Attach your own domain and certificates are issued and renewed for you, wildcards included.
  • Domain ownership is verified when you attach it and re-checked afterwards, rather than trusted once and forgotten.
  • Clusters with no public address publish through a gateway we operate. It terminates no TLS, so your traffic stays encrypted from your visitor to your cluster.

Databases and services

  • PostgreSQL managed by CloudNativePG, with failover, pgvector, and extensions you switch on from the database's own settings.
  • MySQL managed by the Percona operator, fronted by a connection proxy.
  • MongoDB managed by the Percona operator, run as a replica set with a volume of its own.
  • ClickHouse for analytics: aggregations over billions of rows, managed by the Altinity operator.
  • Qdrant for embeddings and vector search, over HTTP and gRPC.
  • Redis running Valkey, as a cache or as a durable instance with its own volume.
  • OpenSearch for full-text search and aggregation queries over your data.
  • RabbitMQ speaking AMQP 0-9-1, so Celery, Bull, Sidekiq and Spring AMQP connect to it unchanged.
  • NATS with JetStream for background jobs and events, so messages survive a restart.
  • S3-compatible object storage on your own cluster, so files and backups have somewhere to go without a cloud account.
  • A mail catcher that holds everything a staging app tries to send rather than delivering it, so a test signup cannot email a real customer.
  • Point a managed database at any S3-compatible bucket and it takes scheduled backups, keeps the history, and requires a final snapshot before it will let you delete the database.
  • Apps bound to a database get their connection details injected, including a DATABASE_URL.

Starting from something

  • One-click stacks. Metabase, Umami, WordPress, Ghost, n8n and OpenClaw each arrive wired to the database, secrets and disk they need.
  • Save any project as a template, then spawn new environments from it.
  • Duplicate a running project, onto the same cluster or onto a different one.

Operating it

  • Stream logs and watch CPU and memory per app, stored on your own hardware on a cluster you attach.
  • Open a terminal inside a running app or database from the console, so you can run one psql without kubectl access to the cluster.
  • Images built from distroless or scratch have no shell to attach to, so Anyport offers to run a debug container beside them instead.
  • Pause a project to scale it to zero without losing any configuration.
  • Attach a persistent disk to an app, so a stateful workload keeps its data across restarts and redeploys.
  • Configs and secrets per project, synced to the right cluster and mounted into your apps.
  • The agent updates itself from the console, so a fleet of clusters does not drift apart.

From your terminal

  • The anyport CLI deploys, tails logs, manages secrets and domains, and opens a shell.
  • It signs in through your browser, so there is no API token to create, store or rotate.
  • anyport dash is a live dashboard of a project inside your terminal.
  • anyport port-forward points psql, DBeaver or any other local tool at a database inside a cluster with no public address, over the connection the agent already holds. It listens on loopback only, and there is no flag to change that.
  • anyport mcp gives an AI agent the same view over MCP. Read-only unless you opt into a write tier, no tier deletes anything, and no tool ever returns a secret's value.

Teams and governance

  • Admin, developer and viewer roles, with access levels per cluster and project, and teams.
  • An audit log of every change.
  • Terminal access is a permission of its own. Restrict it to admins, or switch it off for the whole organization and cut every live session.
  • Every cluster in one organization, managed by one team from one console.

Something missing or wrong? Tell us and it gets fixed.