Managed services

Kafka, RabbitMQ, Redis and Keycloak - what you get, what each arrangement survives, and how an application connects.

A managed service is a piece of plumbing your applications talk to: a cache, a message broker, an event log, a sign-in server. Like a database, it is ordered separately from any application, from the Services page.

The platform creates it, keeps it running and restarts it when it stops. What you put in it is yours.

These four cannot be run as ordinary applications: an image of Redis, RabbitMQ, Kafka or Keycloak is refused there, because an application keeps nothing on disk between deployments.

What is offered

Redis 7.4. Protected by a password. Every write is also logged to disk, so the data survives a restart.

RabbitMQ 3.13. An AMQP broker with one user and a password. Durable queues and persistent messages are kept on disk.

Kafka 3.8. Runs without ZooKeeper. The broker does not ask for a username or a password: the private network is its only boundary.

Keycloak 26.0. A sign-in server of your own, with its admin console. Its realms and users live in PostgreSQL: a low-cost mini-database by default, or a dedicated instance you already own. You can upload your own sign-in themes as a .tar.gz.

If all you need is sign-in for one application, a realm on a Keycloak the platform runs costs less than a server of your own. It is offered on the same page.

Sizes, nodes and price

Sizes are named instance types per region, each shown with its monthly price before you deploy. The price is per node: three nodes cost three times the size.

A region that has not put a price on a service does not offer it. The form says so instead of failing when you submit.

Redis and Keycloak run on 1, 2 or 3 nodes. RabbitMQ and Kafka run on 1, 3 or 5.

What each arrangement survives

One node is the default, and the arrangement that is proven.

It survives a restart: Redis, RabbitMQ and Kafka keep their data on disk, and Keycloak keeps its data in its database.

It does not survive the loss of its machine. The data is on that machine's disk and the service is tied to it, so the service is unreachable until the machine returns.

More nodes are not failover today. Your applications are always given the address of the first node, whatever the count.

Redis. The other nodes follow the first as copies. Nothing promotes one of them if the first is lost.
Kafka. Three or five brokers form one cluster and agree by majority, which is why the count is odd. Clients still make their first contact through the first broker.
RabbitMQ. The additional nodes are started, but they are not joined into one cluster for you. Run one node.
Keycloak. The additional nodes share the same database, but the address leads to the first.

If a service has to survive the loss of a machine, say so before you rely on it.

There are no backups

Redis, RabbitMQ and Kafka are not backed up. Keep in them only what you can rebuild or afford to lose: a cache, work in flight, events that also exist somewhere else.

Keycloak's realms and users are in its PostgreSQL database. Protect them the way you protect any database.

Connecting

On the private network. A service joins one of your organization's networks in its region, chosen when you create it. Applications on that network reach it at the internal address shown on the service. Applications on another network do not.

Credentials. Open the service and choose Show credentials: a connection string, the host, the port, the user and the password. Unlike a database's, they can be shown again later, to anyone allowed to connect to that service. The command line never prints them.

Nothing is set on your application for you. Copy the connection string into the application's environment, as a secret. The exception is the AI Studio: a Redis, RabbitMQ or Keycloak linked to a project arrives there as REDIS_URL, RABBITMQ_URL or KEYCLOAK_URL. Kafka is not linked this way.

Keycloak. Applications use <address>/realms/<realm> as the issuer. The admin console is at <address>/admin/.

Publishing

Keycloak is public by default, at an address of its own, like an application: a sign-in server has to be reached from a browser.

Redis, RabbitMQ and Kafka are private by default in the console. Publishing gives one a host and a port reachable from outside. From the command line a new service is public unless you pass --private.

Three limits to know before you publish:

Encryption is not in force yet. The TLS switch records your choice. A published Redis or RabbitMQ speaks its plain protocol, protected by its password alone.
Keep Kafka private. It has no password, and a client outside the platform is sent back to an address that only exists inside it.
Publishing needs credit. Without it a service stays private, and a Keycloak that would have been public is created private.

A service can be published once it is running.

Resizing

Choose another size and the nodes restart one at a time. With one node that is a short interruption.

Adding nodes creates them. Removing a node deletes that node and the data it held.

Deleting

Every node and all its data are removed, and the credentials with them. It cannot be undone.

Keycloak's database is not deleted with it. A dedicated instance is left untouched, and the mini-database has to be deleted separately.

Edge cases worth knowing before you meet them

The service says it is running and refuses connections. Redis, RabbitMQ and Kafka are marked running as soon as they are created, slightly before they accept clients. Retry.

The application cannot find the service. It is on another network. The service joins one network; put the application on the same one.

A published Kafka accepts the first connection and then fails. That is the limit described above. Use it from applications on its network.

You removed a node and added it back. It starts empty. Its previous data went with it.