Infrastructure
Databases, cache and search
MySQL, Valkey, OpenSearch and RabbitMQ — creating them, attaching them, connecting to them, and deleting them safely.
Magento needs all three. The Deploy button stays disabled until each is attached.
They belong to the team, not to one environment, and are managed under Resources or inline from an environment's Overview.
Compact stack — the cheapest way to start
Instead of three dedicated servers you can add a Compact stack: one server running MySQL, Valkey and OpenSearch together. Attaching its database satisfies all three deploy requirements, and everything else — backups, restores, credentials, the public endpoint — works exactly as it does on a dedicated cluster.
Memory on the shared box is partitioned so no service can starve the others: MySQL and OpenSearch each get a quarter of the RAM, the cache is capped at an eighth. Standard (8 GB) is the sensible minimum for a live store; Small works for staging.
When the store grows, attach a dedicated cache or search cluster — a dedicated resource always takes precedence over the compact box on the next deploy.
Converting an existing store to a compact stack works the other way too: detach the old resources, add a compact stack and deploy. The deploy notices the fresh database is empty and performs a clean install — so this suits a store you are happy to reinstall. To keep your data, download a backup first and bring it back through the existing-store import.
Databases
A cluster is a MySQL server. Inside it are one or more logical databases, each with its own user and password.
Creating a cluster asks for its name, the name of the first database, the MySQL version — 8.0 or 8.4 — and the server size. The engine is always MySQL; MariaDB is not supported.
Add further databases to an existing cluster from the Resources page. Each gets a generated user granted rights to that database only, so two stores on one cluster cannot read each other.
Cache
Valkey 8 — a Redis fork, and what Magento talks to. One cache server carries three separate Redis databases:
| Database | Used for |
|---|---|
| 0 | Magento's default cache |
| 1 | Full page cache |
| 2 | Sessions |
Session locking is disabled deliberately: it is a common source of stalled checkouts under load in Magento 2.
Search
OpenSearch 2, single-node, indices prefixed magento2. Magento 2.4 will not install without a search engine.
Every search server carries the analysis-phonetic and analysis-icu plugins (phonetic matching and ICU tokenisation), which common Magento search extensions expect. Servers built before a plugin was added get it on their next deploy — search restarts once while it is installed.
Attaching and detaching
Attaching stages the change. The store keeps using the old resource until the next deploy — that is what makes a database switch safe, and it is how restores work.
When a deploy finishes, the newest attachment of each type wins and older ones are detached. Detaching never deletes data.
Neither attaching nor detaching is possible during a deploy.
Connecting to your database
Open the credentials dialog from the database on the Resources page. The password is fetched only when you open it, so it is not sitting in the page source.
By default the database is only reachable inside your private network, so connect through your application server:
ssh -L 3306:10.0.1.5:3306 nautvia@203.0.113.10
Then point your client at 127.0.0.1:3306. Your SSH keys are installed on every server, so you can also log in to the database server itself (ssh nautvia@<its public IP>, then sudo mysql) — see Teams.
The public endpoint
A cluster can be opened to the internet with Public endpoint. It adds a firewall rule allowing port 3306 from anywhere.
Password is then the only thing protecting your shoppers' data. No IP allowlist, no VPN. Turn it on for a migration or a one-off analysis, and turn it back off. If you need permanent external access, use the SSH tunnel instead.
Message queues (optional)
A message queue is a dedicated RabbitMQ 4.1 server. Unlike the database, cache and search it is optional: Magento runs without one, falling back to MySQL-backed queues. Attach one when your store uses asynchronous operations, the bulk APIs, or an extension that expects AMQP.
On the next deploy the platform writes the broker credentials into env.php (queue/amqp) and enables cron_consumers_runner, so queue consumers run from the Magento cron — nothing to configure and no consumer processes to babysit. Magento declares its exchanges and queues itself during setup:upgrade.
The broker listens only on your team's private network, with a dedicated account created at provision time — the default guest user is removed.
Deleting
Deletion is refused while something depends on it, and the message says what:
- a logical database attached to any environment, or serving as an environment's live database, cannot be deleted;
- a cluster with any such database cannot be deleted;
- a cache, search cluster or message queue attached anywhere cannot be deleted.
Detach first, deploy so the environment stops using it, then delete. Deleting a logical database also deletes its backups. Deleting a cluster destroys the server and everything on it.