Managed services reference

This page details each managed service: versions, default resources, port and connection format. The fields common to every service are recalled at the top.

Fields common to every deployment

PostgreSQL

Relational database, the most complete service on the platform.

Connection (shown on the service's page):

DATABASE_URL=postgresql://USER:PASSWORD@INTERNAL_HOST:5432/DATABASE

High availability (HA)

PostgreSQL runs in a Blue/Green architecture: an active cluster (blue) and a standby cluster (green). The number of active instances follows the Replicas field. A connection pooler (PgBouncer) sits in front of the database to keep connections stable during a failover.

💡 Increasing Replicas increases the number of instances in the active cluster. Switching to the standby cluster is used in particular during a restore (Blue/Green).

PostgreSQL extensions

Two extensions can be enabled at deployment time, in the PostgreSQL extensions section:

The extension is created when the cluster starts — there is no CREATE EXTENSION for you to run.

ℹ️ PostGIS switches the service's image to a specialized variant. Plan for that choice at deployment time rather than after the fact.

Additional databases

A PostgreSQL cluster can host several databases, on top of the main one created automatically. This is useful to gather several applications on a single cluster while keeping their data separate.

In the Additional databases section, add as many entries as needed:

💡 Give each database its own user to isolate them for real: each application then only reaches its own.

On an already deployed cluster: open the deployment, add the databases in the edit modal, Save, then click Synchronize additional databases to actually create them on the cluster.

MySQL

Connection:

DATABASE_URL=mysql://USER:PASSWORD@INTERNAL_HOST:3306/DATABASE

MongoDB

Connection:

MONGODB_URI=mongodb://USER:PASSWORD@INTERNAL_HOST:27017/DATABASE

Redis

Connection:

REDIS_URL=redis://USER:PASSWORD@INTERNAL_HOST:6379

Redis is deployed with authentication. At deployment time, provide a username and a password:

• user default → Redis's default user is protected by your password;
• custom user → a dedicated user is created and the default user is disabled.

🔒 Access is in any case restricted to your environment's internal network: Redis is never exposed on the Internet.

RabbitMQ

Connection:

RABBITMQ_URL=amqp://USER:PASSWORD@INTERNAL_HOST:5672/

The username and the password are set at deployment time, in the fields provided for that purpose.

RabbitMQ's management interface is available on port 15672.

Kafka

Kafka runs in KRaft mode: no ZooKeeper, each node is both controller and broker.

Connection:

KAFKA_BOOTSTRAP_SERVERS=INTERNAL_HOST:9092
KAFKA_SECURITY_PROTOCOL=SASL_PLAINTEXT
KAFKA_SASL_MECHANISM=SCRAM-SHA-512
KAFKA_SASL_USERNAME=USER
KAFKA_SASL_PASSWORD=PASSWORD

ℹ️ The username shown may differ from the one you typed. Kafka uses the resource name as the SASL identity: Nubiecloud normalises it (lowercase, hyphens) and appends a unique suffix. Always copy the user exactly as it appears on the deployment page.

Retention

Messages are kept for 7 days, the last 2 days on the broker's local disk. Beyond that they are deleted — Kafka is a log with a limited lifetime, not durable storage.

Size the storage accordingly: a producer writing 1 GB per day needs at least 7 GB, before replication.

Built-in Kafka console

Every Kafka deployment gets a console in the interface, under the Kafka tab:

• Topics — list, create, inspect configuration and partition count.
• Consumer groups — see active groups, their state and their consumption lag.
• Messages — browse a topic's contents to check what is flowing through.

The console opens an ephemeral session that connects to the broker with your credentials, injected at runtime. It is restricted to the project's Developer and Admin roles.

On deletion

Deleting the deployment destroys the data volume, and with it any messages still held in the topics. Kafka has no platform-side backup: whatever has not been consumed is lost.

The console states what is about to be destroyed before asking for confirmation. For a deployment you do not want to lose by accident, turn on deletion protection: while it is on, deletion is refused.

Keycloak

Identity server: authentication, SSO and user accounts for your applications, through OIDC and SAML.

Keycloak is the only managed block that is an application: it has a public URL and an admin console in the browser.

Prerequisite: a managed PostgreSQL

Keycloak does not bundle its database. It stores your realms, users, clients and signing keys in a managed PostgreSQL that you pick at deployment — and that stays yours, with its backups, its SQL console and its metrics. Nubiecloud automatically creates a dedicated database on it, which then shows up in your SQL console.

You therefore need a managed PostgreSQL in the same environment before deploying Keycloak. If there is none, create it first.

ℹ️ Some PostgreSQL instances may appear greyed out in the list, with a reason: those were created with an earlier version of the model and do not allow the required administrative operations. Create a new one, or contact support.

Deployment fields

Keycloak departs from several common fields: no password to enter, no storage to size, no application database.

The administrator password

At the end of the deployment, the console shows once the address of the admin console, the username admin and the generated password.

⚠️ Write this password down before closing the dialog. It is not shown again. If you lose it, contact support.

Once signed in, change it from Keycloak (Users → admin → Credentials): the account created at deployment is a bootstrap account.

The first start takes two to three minutes, while Keycloak initialises its schema. An error page during that window is expected.

Connecting an application

Create a client in the Keycloak console, then configure your application with the discovery URL — most OIDC libraries only need this one and derive the rest from it:

https://YOUR-KEYCLOAK.apps.nubiecloud.io/realms/YOUR-REALM/.well-known/openid-configuration

⚠️ If you add a custom domain, tokens are still issued on the generated address. That is the one to configure in your applications: it is written into every token and never changes.

On deletion

Deleting the deployment also destroys its database on the host PostgreSQL: realms, users, clients and signing keys are lost, and applications that authenticate through this Keycloak stop working.

The console names the database and its PostgreSQL before asking for confirmation. Turn on deletion protection so an accidental click is refused.

The host PostgreSQL itself is not deleted — your other databases on that cluster are untouched.

Current limits

Single instance (no high availability), a single version kept up to date by the platform, and an upgrade briefly interrupts the service while the schema migrates.

n8n

Workflow automation: connects your applications together — APIs, databases, email, webhooks — without writing integration code.

Prerequisite: a managed PostgreSQL

n8n does not bundle its database. Your workflows, executions and stored credentials live in a managed PostgreSQL — yours, with its backups, SQL console and metrics. Pick one at deployment, or let Nubiecloud create one.

The temporary access, and why it exists

Unlike Keycloak, n8n has no administrator account when it is created. It asks for one the first time its address is opened — and creates it for whoever visits first.

Nubiecloud therefore puts an authentication in front of the application while you set it up. The console shows the username nubie and a generated password once.

⚠️ Write this password down before closing the window. It is not shown again.

The flow is:

1. Open the address and sign in with those credentials.
2. Create your owner account in the n8n wizard.
3. Go back to the deployment page and click "I have finished setting up — remove the temporary access".

Until you remove it, you sign in twice on every visit. Once removed, the application is protected by its own account.

You can put it back at any time from the same page: a new password is generated and shown once. The previous one stops working.

Deployment fields

n8n departs from several common fields: no password to enter, no storage to size.

The first start takes one to two minutes, while n8n initialises its schema.

On deletion

Deleting the deployment also destroys its database: workflows, execution history and stored credentials are lost. The console names the database before asking for confirmation.

The host PostgreSQL itself is not deleted.

Current limits

Single instance, no queue mode and no separate workers: executions run in the same process. One version kept up to date by the platform.

Metabase

Business intelligence: dashboards, questions and charts on your own databases.

ℹ️ Two databases, not to be confused. The host PostgreSQL stores what Metabase produces — questions, dashboards, accounts. The databases you analyse are connected afterwards from within Metabase, and may live elsewhere.

Prerequisite: a managed PostgreSQL

Like n8n, Metabase keeps its own data in a managed PostgreSQL from your environment. Pick one at deployment, or let Nubiecloud create one.

The temporary access

Metabase has no account until its wizard has been completed, and the first visitor becomes its administrator — with access to every database you later connect to it. The same protection as n8n applies: credentials shown once, to be removed once your account exists. See the detailed flow.

Deployment fields

The first start takes two to three minutes: Metabase runs its migrations and builds its search index. An error page during that time is normal.

Connecting a database to analyse

From Metabase: Settings → Databases → Add. For a managed database in the same environment, use its internal address (shown on the deployment page) and the database credentials.

On deletion

Deleting the deployment also destroys its database: questions, dashboards and accounts are lost. The databases you were analysing are not touched — Metabase only connects to them.

Current limits

Single instance. The open source edition: no paid features (data sandboxing, advanced embedding, SSO authentication).

Hasura

An instant GraphQL API over your PostgreSQL databases: connect a database and Hasura exposes its tables for reading and writing, without writing a line of server code.

ℹ️ Two databases, not to be confused. The host PostgreSQL stores what Hasura remembers — the declared databases, permissions and relationships. The databases you expose over GraphQL are connected afterwards from the console, and may live elsewhere.

Prerequisite: a managed PostgreSQL

Like n8n and Metabase, Hasura keeps its own data in a managed PostgreSQL in your environment. Pick one at deployment time, or let Nubiecloud create one.

The admin secret

Unlike n8n and Metabase, Hasura has no first-run wizard: its admin secret is set at the very first boot and the API is closed immediately. There is therefore no temporary access to remove.

• The secret is shown once, at creation. Keep it: it is not stored anywhere you can read it back.
• There is no username — the secret alone opens the console.
• It also signs admin calls to the API, through the x-hasura-admin-secret header.

Deployment fields

The first start takes one to two minutes: Hasura creates its metadata schema. A 503 response during that time is normal.

Exposing a database over GraphQL

From the console: Data → Connect Database.

⚠️ The form offers "Environment variable" by default. Your managed databases are not declared as environment variables: choose Database URL and enter the connection address by hand.

The address looks like postgres://user:password@internal-address:5432/database. The internal address and the exact database name are shown on the PostgreSQL deployment page — the database name is not the application name.

Once the database is connected, Data → Track All publishes the tables into the GraphQL schema. Until a table is tracked, it stays invisible to the API.

ℹ️ On the first visit, a welcome dialog with a video overlays the console and intercepts clicks. Close it before starting.

Opening the API to your applications

By default everything is closed: without the admin secret, no query goes through. To let an application query the API without holding that secret, define roles and permissions per table (the Permissions tab of a table). That is the intended mechanism — never hand the admin secret to a client.

On deletion

Deleting the deployment also destroys its metadata database: declared databases, permissions and relationships are lost. The databases you were exposing are not touched — Hasura only connects to them.

Current limits

Single instance. The community edition: no paid features (query caching, enterprise mode, proprietary connectors).

DocuSeal

Electronic document signing: upload a contract, name the signers, and DocuSeal collects their signatures and returns the signed document.

ℹ️ DocuSeal uses one NubiS3 bucket. It is created with the application and deleted with it. It counts towards your object storage quota — on the Free plan, which grants a single one, DocuSeal is therefore the only application of this kind you can deploy, and you cannot keep a bucket for direct use at the same time.

Prerequisite: a managed PostgreSQL

Like the other managed applications, DocuSeal keeps its data in a managed PostgreSQL in your environment. Pick one at deployment time, or let Nubiecloud create one.

Temporary access

DocuSeal has no account until its wizard has been completed, and the first visitor to its address becomes its owner — with access to every document that passes through it afterwards. These are signed contracts: the same protection as for n8n applies, credentials shown once, to be removed once your account exists. See the detailed walkthrough.

Deployment fields

The first start takes two to four minutes: DocuSeal runs all its migrations. An error page during that time is normal.

Where documents go

Into a dedicated NubiS3 bucket, never onto the server's disk. That is what lets the application have no volume of its own: it can be restarted, moved or upgraded without losing anything.

The bucket appears in NubiS3 under the application's name. You can see what it holds, but you cannot delete it while the application exists: that would remove the storage from under a running application, which would keep looking healthy while losing every document uploaded to it.

Sending a document for signature

From DocuSeal: New Document → upload a PDF → place the signature fields → add the signers. Each one receives a link by email.

ℹ️ Sending email requires SMTP configuration. Without it, DocuSeal creates the signing links but does not send them: you have to copy them from the interface and pass them on yourself. Configure it in DocuSeal, Settings → Email.

On deletion

Deleting the deployment destroys two things:

• its database — templates, signers, signing history;
• its bucket — signed documents and their attachments, permanently.

The console tells you so in the confirmation dialog. Download anything you want to keep beforehand.

Current limits

Single instance. Community edition, under the AGPL licence. Work in progress at the time of a restart is not resumed.

Open WebUI

A chat interface over language models: a single entry point for your teams, and the ability to have the model read your own documents.

⚠️ Nubiecloud provides no model. Open WebUI is the interface, not the engine: you connect the provider of your choice, with your own API key. This is deliberate — none of your conversations goes to a model you did not name, and Nubiecloud bills you no inference.

ℹ️ Open WebUI uses one NubiS3 bucket, created with the application and deleted with it. Like DocuSeal, it counts towards your object storage quota — on the Free plan, which grants a single one, you cannot deploy both at the same time.

Prerequisite: a managed PostgreSQL carrying the vector extension

Open WebUI does not only keep its conversations in its host PostgreSQL: its document index goes there too, as vectors. That is what spares it a disk of its own — and what requires the vector extension (pgvector) on the host database.

That extension can only be installed when the PostgreSQL is created. In practice: a managed PostgreSQL created without it cannot host Open WebUI. The console tells you so by greying out the choice, with the reason, rather than letting the deployment fail later. If you let Nubiecloud create the PostgreSQL, it comes with the extension.

The administrator account

Unlike n8n, Metabase and DocuSeal, Open WebUI has no temporary access to remove: its administrator account is created at first start, so the application is protected from its very first second.

• The username is an address of the form admin@<your-application-address>.
• The password is shown once, at creation. Write it down: it is displayed nowhere else, and is changed from within the application afterwards.
• As soon as that account exists, sign-up closes: nobody can create an account from the login page.

To open accounts for your colleagues: Admin Panel → Users. You can reopen sign-up there — be aware that any visitor to the public address will then be able to create an account.

Deployment fields

The first start takes several minutes: Open WebUI runs its migrations, then downloads its local indexing model (all-MiniLM-L6-v2). An error page during that time is normal; the application is given seven minutes before being considered failed.

Connecting your model provider

In Open WebUI: Settings → Connections → OpenAI API, then fill in the base URL and your key. Any provider exposing an OpenAI-compatible API works.

Ollama is disabled: the platform hosts no model server. Left enabled, Open WebUI would look for a server that does not exist at every start.

Your documents

The files you upload go to the application's NubiS3 bucket. Their vector index, however, lives in the host PostgreSQL: it weighs on that database's storage, not on the bucket's.

Indexing is done locally, by the model embedded in the application: the content of your documents is not sent to a third party to be indexed. It does go to the provider you connected at the moment you ask a question — that provider is the one answering.

On deletion

Deleting the deployment destroys two things:

• its database — conversations, accounts, document index;
• its bucket — the uploaded files, permanently.

The console tells you so in the confirmation dialog. Download whatever you want to keep first.

Current limits

Single instance. No model provided by the platform. Community edition, under the BSD-3-Clause licence.

SQL console

For PostgreSQL databases, Nubiecloud embeds a SQL console in the interface: run queries straight from the console, with no client to install.

• Available for: PostgreSQL only.
• How: open the PostgreSQL deployment → SQL tab → type your query → run it. The result comes back in the console.
• Choosing the database: if the cluster hosts additional databases, a Database selector lets you choose the one the query runs against. The targeted database is recalled above the editor.
• Under the hood: each query runs in an isolated, ephemeral task, with credentials injected at runtime (never exposed).
• Access: restricted to the project's Developer and Admin roles.

⚠️ You are responsible for the queries you run. Modifications (INSERT, UPDATE, DELETE, DROP…) are irreversible — the console has no undo button.

See also

• Managed services — overview
• Backups & restore