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.

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#

Every entry has a page of its own under /services, with the options the console offers and the variables a bound app receives. The list here is the short form.

Databases#

• PostgreSQL — Managed by CloudNativePG, with high availability, automatic failover, and pgvector included; PostGIS and fourteen more extensions are switches in the database's settings, and optional PgBouncer pooling in front. 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. Details
• 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. Details
• MariaDB — Managed by the MariaDB operator, speaking the MySQL protocol so every MySQL driver connects unchanged. Bound apps get a DATABASE_URL. Project-scoped. Details
• 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. Details
• 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. Details
• QuestDB — Time-series database you query in SQL: ingested over ILP, read through any Postgres client or its own web console. Binds under a QUESTDB_ prefix. Project-scoped. Details
• InfluxDB — Time-series database for metrics, sensor readings and events, queried with Flux or InfluxQL, with old data expired by bucket retention. Binds under an INFLUX_ prefix. Project-scoped. Details
• Neo4j — Graph database for connected data, traversed with Cypher over Bolt and HTTP. The community edition. Binds under a NEO4J_ prefix. Project-scoped. Details
• CouchDB — Document database with replication built in, so PouchDB and mobile apps can work offline and catch up later. A single node. Binds under a COUCHDB_ prefix. Project-scoped. Details
• 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. Details
• Weaviate — Vector database with hybrid search: similarity, keyword and filtered queries in one, over HTTP, GraphQL and gRPC. Binds under a WEAVIATE_ prefix. Project-scoped. Details
• Chroma — The vector store most RAG tutorials start on, behind the API the chromadb clients already speak. Binds under a CHROMA_ prefix. Project-scoped. Details

Caching#

• 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. Details
• Memcached — The flat in-memory cache Django, Rails, Laravel and PHP sessions expect out of the box. One option, the memory size. Bound apps get MEMCACHED_HOST, MEMCACHED_PORT and MEMCACHED_SERVERS. Project-scoped. Details

Search#

• 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. Details
• Typesense — Typo-tolerant, faceted search-as-you-type from one process that keeps the whole index in memory. Binds under a TYPESENSE_ prefix with a generated API key. Project-scoped. Details
• Meilisearch — Search-as-you-type for your product: typo-tolerant, ranked, faceted results from a single small process. Binds under a MEILISEARCH_ prefix with a generated master key. Project-scoped. Details

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. Details
• 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. Details
• Kafka — Event streaming with partitioned, replayable topics, managed by Strimzi. Bound apps get KAFKA_BOOTSTRAP_SERVERS and SASL credentials, so every Kafka client library connects unchanged. No public port: brokers hand clients internal addresses. Project-scoped. Details
• MQTT broker — EMQX, speaking MQTT 3.1.1 and 5.0 over TCP and WebSocket, for devices and mobile apps. Binds under an MQTT_ prefix; both client ports can be opened on a public cluster. Project-scoped. Details
• Centrifugo — Real-time messaging: browsers hold a WebSocket or SSE connection, your backend publishes to channels over an HTTP API. Binds under a CENTRIFUGO_ prefix with the API key and token secret. Project-scoped. Details
• SQS queue — An Amazon SQS-compatible queue (ElasticMQ), so the AWS SDKs, Laravel and Celery connect to it by endpoint. Standard and FIFO queues, named at install, with messages journaled to a volume. Binds under an SQS_ prefix rather than AWS_, so your app's real AWS credentials are left alone. No authentication, so it stays inside its project. Project-scoped. Details

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. Details

• SFTP server — SFTPGo, for the files your partners, customers and apps exchange: accounts with their own home directories, reachable over SFTP and a web client. Bound apps get the admin credential and API URL under an SFTP_ prefix, which is how they create accounts. The SFTP port can be opened on a public cluster. Project-scoped. Details

  Two things to know before you rely on it. It holds one administrative credential for the whole cluster: every app that references it gets the same key and can reach every object on it, so per-app isolation waits on per-bucket keys. And uninstalling it deletes every object it holds, including database backups written there.

AI#

• Ollama — Open-weight language models on your own hardware, behind the API every Ollama client and most OpenAI-compatible SDKs speak. Name the models to pull; optionally schedule onto a GPU node. Binds under an OLLAMA_ prefix. Project-scoped. Details
• Speech to text — Whisper transcription and translation, plus text-to-speech, behind the OpenAI audio API (Speaches). The model you name is downloaded before the service starts. Binds under a SPEACHES_ prefix with a generated API key; SPEACHES_URL is the base URL the OpenAI SDK wants. Project-scoped. Details
• Text embeddings — Embeddings and reranking for search and RAG with any compatible Hugging Face model (Text Embeddings Inference, on CPU). The model you name is downloaded before the service starts. Binds under an EMBEDDINGS_ prefix with a generated API key; EMBEDDINGS_OPENAI_BASE_URL is what the OpenAI SDK wants. Project-scoped. Details

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. Details
• Headless browser — Chromium your apps drive over the DevTools Protocol with Puppeteer, Playwright or chromedp, for scraping, screenshots, PDFs and end-to-end tests. Bound apps get BROWSER_URL. No authentication, so it stays inside its project. Project-scoped. Details

Build#

• Container registry — A registry on your own cluster for the images your builds produce (zot). Once it reports healthy, builds on the cluster push to it ahead of your organization's default registry, unless their app names another, and nodes pull with a separate read-only credential; both credentials are generated on the cluster and kept there. It keeps the 10 most recent images of each app, which is also your rollback window, and 14 days of build cache, and never removes an image an app is running. Its images cannot be pulled from another cluster, and uninstalling it deletes every one, so Anyport refuses while an app is still running one. The console still marks the entry as new. Not offered on Anyport Cloud, where builds push with a registry credential instead. Cluster-scoped. Details
• GitHub Actions runners — Self-hosted runners for your GitHub workflows on your own cluster, scaled per job by GitHub's Actions Runner Controller: each job gets a fresh pod, and with a minimum of zero nothing runs between jobs. Point it at an organization or a repository (the URL is filled in from your GitHub connection) with a personal access token, and workflows target it with runs-on: <runner name>. Install it once per label you want; every set on a cluster shares one controller. Docker-in-Docker mode lets jobs run docker build. The token is written to the cluster and never stored by Anyport, and the runner name is fixed once installed, because GitHub keeps the label a set registered with. Runners live beside Anyport's own builds rather than inside any project, and the console still marks the entry as new. Not offered on Anyport Cloud, which does not run privileged containers. Cluster-scoped. Details

Observability#

• Observability — Metrics, logs and traces together, in one click. It installs a metrics store, a log store and a trace store with lightweight, project-scoped collectors. Not needed on Anyport Cloud, where logs and metrics are already included. Cluster-scoped. See Logs & metrics and the details.

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, Anyport refuses the install and says what to fix. Check with kubectl get storageclass and see Cluster requirements.

Storage can be raised from a service's settings after it exists, as long as the cluster's storage class allows expansion; it can never be reduced. A service's Overview shows its disk: the size the cluster gave it, how full it is, and its class. Most services keep their data in a StatefulSet, whose volume template Kubernetes will not change; for those, Anyport's agent grows the volume and recreates the StatefulSet around the running pods, which needs an agent recent enough to do it. On an older agent the size field stays locked and says to update the agent.

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.