← Documentation

Managed services

Services are the databases, caches, and tooling your apps depend on. You add one from a catalog, Anyport provisions it inside your own project, and connection details are wired into your apps for you.

Everything runs on your servers. Anyport provisions and manages it; it never leaves your infrastructure, and there is no per-service fee.

Adding a service

  1. Open a project and go to Services.
  2. Pick a service from the catalog and choose its options—size, replicas, persistence, and so on. The options differ per service.
  3. Create it. Anyport installs it into the project's namespace and tracks its health.

Connection binding

When a service exposes a connection, Anyport generates the credentials and stores them in a secret inside the same project. Instead of copying a password into your app's environment by hand, you bind the app to the service and the values arrive as environment variables.

The values arrive under a prefix named after the service, so a Redis binding gives your app REDIS_URL, REDIS_HOST, REDIS_PORT and REDIS_PASSWORD. Bind a second cache and it gets its own prefix rather than overwriting the first.

The password is generated once into a secret in the same project, and reaches your app as environment variables rather than as something you copy.
The password is generated once into a secret in the same project, and reaches your app as environment variables rather than as something you copy.

This matters more than it sounds: the credential is generated once, never displayed in plain text, and rotating it doesn't mean hunting through every app's config.

Project scope and cluster scope

A service is scoped one of two ways, and the scope is a property of the service rather than a choice you make.

Project-scoped services are created inside a project, alongside the apps that use them. Each project gets its own instance with its own storage and credentials, and two projects never share one. Databases, caches and queues work this way, because sharing a database between environments is the thing project isolation exists to prevent.

Cluster-scoped services are installed once per cluster and serve everything on it. Observability and object storage work this way, because a metrics store per project would be a dozen half-empty copies of the same thing.

The catalog

Databases

  • PostgreSQL — Managed by CloudNativePG, with high availability, automatic failover, and pgvector included. Bound apps get a DATABASE_URL. Point it at an S3-compatible bucket you own and it also backs itself up on a schedule, keeps the backup history, and takes a final snapshot before it will let you delete it. Project-scoped.
  • MySQL — Managed by the Percona operator, provisioned with a volume and fronted by a connection proxy. Bound apps get a DATABASE_URL. Point it at an object store you own and it backs itself up there. Project-scoped.
  • Redis — In-memory store for caching, sessions, and queues. Runs Valkey and speaks the Redis protocol. Choose Cache (fastest, evicts under pressure, empty after a restart) or Durable (keeps a volume and your data), pick a size, and bind it to your apps. Project-scoped.
  • MongoDB — Document database managed by the Percona operator, provisioned with a volume and run as a replica set. Bound apps get MONGODB_URL alongside the host, port, database, username and password. Project-scoped.
  • ClickHouse — Column-store database for analytics: aggregations over billions of rows, event and metric tables, dashboards you own. Managed by the Altinity operator, and bound apps get their connection details under a CLICKHOUSE_ prefix. Project-scoped.
  • Qdrant — Vector database for embeddings, so similarity search, recommendations and retrieval for AI apps have somewhere to live. Speaks HTTP and gRPC, and binds under a QDRANT_ prefix. Project-scoped.
  • OpenSearch — Full-text search and analytics over your data: it indexes documents, ranks results, and answers aggregation queries. The Apache-licensed fork of Elasticsearch. Bound apps get their connection details under an OPENSEARCH_ prefix. Project-scoped.

Messaging

  • RabbitMQ — A message broker for background jobs, work queues and pub/sub, speaking AMQP 0-9-1, so Celery, Bull, Sidekiq and Spring AMQP connect to it unchanged. Bound apps get RABBITMQ_URL, RABBITMQ_HOST, RABBITMQ_PORT, RABBITMQ_USERNAME, RABBITMQ_PASSWORD and RABBITMQ_VHOST. The management UI runs on a Service of its own, so publishing the dashboard cannot put the broker's client port on the internet beside it. Project-scoped.
  • NATS — A message queue and streaming server for background jobs, events and pub/sub, running with JetStream so messages survive a restart. Bound apps get NATS_URL, NATS_HOST, NATS_PORT, NATS_USERNAME and NATS_PASSWORD. The disk you give it holds messages that have not been consumed yet. Project-scoped.

Storage

  • Object storage — S3-compatible storage running on this cluster, so your databases have somewhere to back up to and your apps have somewhere to keep files without a cloud account. Install it and it becomes selectable as a backup destination for Postgres and MySQL. Cluster-scoped.

    Two things to know before you rely on it. It is not bindable to apps: it holds one administrative credential for the whole cluster, and handing that to every app would let any app read any other project's objects, so per-app access waits on per-bucket keys. And uninstalling it deletes every object it holds, including database backups written there.

Development

  • Mail catcher — Catches every email your apps send and shows it in a web inbox instead of delivering it, so a test signup cannot email a real customer. Bound apps get SMTP_HOST, SMTP_PORT and SMTP_FROM, which is usually all your mailer needs to point at it. Intended for development and staging projects. Project-scoped.

Observability

  • Observability — Metrics and logs together, in one click. It installs a metrics store and a log store with lightweight, project-scoped collectors. Cluster-scoped. See Logs & metrics.

Before you add a stateful service

Everything above that keeps data asks your cluster for a volume, which means the cluster needs a default StorageClass. Without one the claim is never filled and the service waits forever rather than failing. Check with kubectl get storageclass and see Cluster requirements.

Storage sizes are immutable once a service exists. Kubernetes cannot resize a running service's volume in place, so changing the size means creating a new instance at the size you want and moving over, rather than editing the old one.

Services change what the platform does

This is the part that makes services more than a package manager. Installing a service can change how Anyport itself behaves.

Install Observability, and your apps' logs and metrics start coming from that service rather than from raw Kubernetes—longer retention, real queries, proper history. You didn't configure a data source or point anything at anything; the platform noticed what you installed and rewired itself.

The same pattern applies as the catalog grows: what you install determines what the console can show you.

Next steps

  • Apps — Bind a service to an app.
  • Logs & metrics — What Observability turns on.
  • Projects — Services are scoped to a project.