GuidesOnly show guides for your app
GuidesGuidesMongoDB, PostgreSQL, and Redis can each run as a full server application inside your own container — when that's the right call, and when a managed database is safer.
The Databases page hands you a managed database on a shared host. But the Applications tab has another option: run the database engine itself as your server's application, in your own container. Same software, very different trade-offs — and the trade-offs are the whole point of this guide.
| At a glance | |
|---|---|
| You need | A fresh or spare Falix server you can dedicate to the database |
| Helps to know | How app hosting works |
| Plan | Any |
⚠️ Heads up: Switching a server's application reinstalls it and wipes its files, so use a fresh or spare server, not one already doing a job.
On the Applications tab when creating a server (or by switching an existing server's application in Settings), you'll find three database engines as first-class applications:
Each runs the real engine inside your server container, listening on your server's single public port — the SERVER_PORT value the panel injects. Credentials are generated for you at install time and shown in the variables section of the Settings page:
admin.pterodactyl.You don't configure any of this by hand — install the application, open Settings, and read the values out.
Running your own database server makes sense when:
Here's the honest part. A database is only useful if it's running whenever something needs it — and a database application is just another server, subject to the same rules as any other:
A managed database (Add a database) has none of these problems: it lives on an always-on shared host and survives sleeps, reinstalls, and application switches. So the rule of thumb is simple.
| Managed | Your own server | |
|---|---|---|
| Where it runs | Always-on shared host | Inside your server container |
| On a free timer stop | Keeps running | Stops answering — dependent apps throw connection errors |
| Reinstall / app switch | Data untouched | Container files wiped, including stored data |
| Control & version | Kept hidden | Superuser access; you pick the version and tune it |
| Redis | Not offered | Available (Redis 7) |
If other things depend on the data staying available, prefer a managed database. Run your own database server when you specifically need Redis, a feature managed doesn't expose, or a stack you're deliberately keeping online anyway — realistically, a premium server that runs 24/7.
⚠️ Heads up: Don't put your only copy of important data in a free server's own engine and walk away — the next timer expiry takes it offline.
Once the database application is installed and started, connect to it from your code (or from another server) exactly like any external database:
localhost — inside another server, localhost points at that server's own container, not this one.From there it's the same driver pattern as any other database — build the connection URL from the address, port, and credentials, keep it in .env, and read it in code, exactly as in Connect your app to a database. For Redis, point a Redis client at the address and port with the Redis Password value.
The install-time passwords live in Settings → variables, but how you change one depends on the engine:
db.changeUserPassword(...) in Mongo, an ALTER USER ... WITH PASSWORD ... in Postgres), then update the password in your connection string to match. A reinstall would regenerate the credentials from the variables, but it wipes the stored data too, so it's not a password-change tool.Start the server and watch the Console for the engine's own startup log — Mongo, Postgres, or Redis announcing it's ready for connections. Then connect from a client using the public address, port, and credentials. A successful Redis PING, or a "list databases" query on Mongo/Postgres, confirms it's reachable from outside the container.
localhost.