Chapter 06
Databases, Redis and mounts
MySQL and Redis run alongside your site on the internal network. You reach them by name, from inside your container, with no ports and no host addresses involved. One more thing can be given to a site from outside it: a folder belonging to another of your sites, which is the last section here.
Connecting
From a catalog site the hostnames are literally mysql and redis. Neither is reachable from the public internet or from your laptop — only containers on the internal network can see them.
A stack's containers sit on their own compose network, where mysql and redis do not resolve. Use the platform aliases the panel injects on every deploy:
mysql.nimbus:3306
redis.nimbus:6379Everything on the Databases page works identically for both kinds. The Host it displays is the platform-internal name — that is what phpMyAdmin connects with — while Apply to .env writes whichever name your site can actually resolve. See chapter 02.2.
You do not have to remember which pair is which. The panel's System information page — in the panel's menu, and readable by any account signed in from an unlocked address — lists both under Technical, one row for sites and one for stacks.
In a Laravel .env, that comes out as:
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=your_database
DB_USERNAME=your_user
DB_PASSWORD=your_password
REDIS_HOST=redis
REDIS_PORT=6379The mysql and redis PHP extensions are both compiled into the image, so no further installation is needed.
.env says REDIS_HOST=127.0.0.1, change it
The panel used to state the Redis host for sites as 127.0.0.1, which was simply wrong — inside your container that address is the container itself, where nothing is listening. It now reads redis, and that is the value to use. If you copied the old one, Redis has never worked for that site.
You can edit these values, and the rest of your .env, straight from the panel: open your site and pick the Environment tab. It shows the live .env exactly as stored; save your changes there, then restart the site so it reads them. This page is the same for both kinds of site — only the file it points at differs.
Open your site, pick the Databases tab, then Create database. The panel makes a MySQL database and a user for you — the name and username are derived from the site's domain, or from a stack's slug; the password is generated — and shows you all four values (database, username, password, host). No need to ask your operator.
Static sites have no Databases page. nginx serving files has no runtime that could open a connection, so there is nothing the credentials could be used by. If you need one, you need an image or a stack that runs code — chapter 02.
You do not have to copy them by hand: press Apply to .env and the panel writes the DB_* lines above straight into your .env, leaving everything else untouched. Then restart the site so it picks them up.
You can Reset password at any time, or Drop database to delete it — dropping asks you to confirm because it permanently destroys the data.
Redis is durable, not disposable
Redis is configured to persist to disk and — importantly — not to evict keys when memory fills up. When it runs out of memory, writes fail loudly instead of data silently disappearing.
That is a deliberate choice for queues and locks: a job quietly evicted from a queue is a job that never runs and never errors. The consequence for you is that Redis is not a throwaway cache you can fill without thinking. If you cache heavily, set expiry times on what you write. Unbounded, un-expiring writes will eventually cause failures rather than quietly making room.
It is shared with other sites, so key prefixes matter. Laravel's default cache and queue prefixes derive from your app name — set APP_NAME to something distinctive and you get separation for free.
phpMyAdmin
If your operator has published it, phpMyAdmin is available for browsing and editing your database in the browser. Sign in with the username and password from your site's Database tab — the same credentials the panel generated. It is intended for site owners, not just the operator.
You do not have to ask for the address: System information → General links straight to it. If no phpMyAdmin has been set up on this box, the page says so rather than offering a link that goes nowhere — which is your answer too.
phpMyAdmin is permanently restricted to unlocked IP addresses. From anywhere else it returns a 403 with no explanation — the same bare refusal described in chapter 08. If you get one, unlock your IP address first, then reload.
What else is on the network
Your container can reach other containers by name, but there is nothing else you are expected to use. There is no shared object storage, mail relay, or search service provided by the platform. Anything else your app needs is an external service you configure yourself, reached over the internet as normal — outbound connections are not restricted.
Files are a separate question from the network, and there is one arrangement for them.
Folders from another site
A site can be given access to a folder that belongs to a different site on the same box. It appears inside the container as an ordinary directory, at a path fixed when the arrangement is made. The case it exists for: one app writes files — a generated download, a shared configuration — and another site has to serve them.
A catalog site's Mounts tab lists what it can reach beyond its own folder. Each row names the site the folder comes from, which folder inside that site, where it appears in this one, and whether this site can write to it or only read it.
On your own sites the tab is read-only. There is no add, edit or remove button, and its absence is not something to hunt for — ask your administrator instead, naming both sites, the folder, and whether it has to be writable. Two sites can only be paired when they have the same owner, so the folder you want has to be on another site of yours.
The folder also has to exist before the mount can be made. Nothing is ever created for you here.
Write access is a tick-box, and leaving it unticked is the right default: the site reads the files and cannot change them. Ask for write access only for the site that actually produces them.
Mounts are fixed as the container is built, so restarting a site leaves them exactly as they were. This is the usual reason a mount that was set up an hour ago is still not there. Every row says which state it is in — Running for one that is in place, Pending recreate for one that is not — and the Recreate button sits on the same page. Chapter 02.1 draws the line between the two buttons.
The path a mount lands on has to be outside /var/www/virtual/<your-domain>. Your own tree is wiped and re-published by every deploy (chapter 04), so a folder mounted into it would be sitting exactly where a deploy is about to write. Somewhere under /mnt/ is the habit to get into.
If your application insists on finding the files inside its own directory, have the deploy create a symlink to the mount path. Two mounts cannot overlap either — one folder, one place.
A mount exists inside the site's running container. An SFTP session (chapter 04) is looking at the site's folder on the server, so it does not carry the mount. The files stay where they are, in the folder of the site that owns them.
When the source is not there
The folder a mount points at can go missing: deleted, renamed, or on a site that has not been restored yet. When that happens your site still starts. That one mount is skipped and everything else about the site behaves normally. A broken mount costs you a folder, not the site.
You find out in two places. The row on the Mounts tab reads Source missing and gives the path it looked for, and the site carries a warning on the sites list. Nothing is put there in place of the missing folder — no empty directory is created — so an application reading that path finds nothing at all.
Putting the folder back is the whole fix. It is applied by itself on the next recreate after that, and a recreate before the folder is back does nothing, which is why this state is shown differently from Pending recreate.
Who depends on your site
The same tab has a Mounted by section, listing the sites that reach into this one's folder. It matters at one moment above all: a site whose folder is mounted cannot be deleted. The delete is refused, and the message names the sites that depend on it — those mounts have to go first, which is an administrator's job. Handing a site to a different owner is refused on the same grounds, because a mount cannot cross from one owner to another.
Locking decides who is served over HTTP and nothing else (chapter 08). It is not a control over files: a mount keeps working while either site is locked.
This is a catalog-site arrangement. A custom stack composes its own services from its repository, and is offered no Mounts tab.