Run your own database server

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.

⚠️ 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.

The three database applications

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:

• MongoDB 8
• PostgreSQL 17
• Redis 7

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:

• MongoDB creates an admin user named admin.
• PostgreSQL creates a superuser named pterodactyl.
• Redis puts its password in the Redis Password variable.

You don't configure any of this by hand — install the application, open Settings, and read the values out.

When this is the right call

Running your own database server makes sense when:

• You need Redis. Redis isn't offered as a managed database, so if you want an in-memory cache or a fast key/value store — for instance, to sit in front of another one of your servers — running the Redis application is how you get one on Falix.
• You want full control. It's your engine: you pick the major version (Mongo 8, Postgres 17, Redis 7), you have superuser access, you tune it. A managed database deliberately keeps that hidden.
• You're building a self-contained stack. A web app on one server talking to a Postgres server you own, or a bot caching in a Redis server you own, is a clean setup you fully control.

The catch you have to respect

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:

• On a free plan, the server stops when its session timer runs out. A database that has stopped answers nothing: every app depending on it starts throwing connection errors the moment the timer expires. Uptime pingers don't rescue you — they don't extend the timer. See Keeping apps online.
• A reinstall or an application switch wipes the container's files — including the database's stored data.

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.

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.

Connecting to it

Once the database application is installed and started, connect to it from your code (or from another server) exactly like any external database:

• Host and port: your server's public address and port, from the Network page. Not localhost — inside another server, localhost points at that server's own container, not this one.
• Credentials: the username and password from the Settings variables above.

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.

Changing the generated password

The install-time passwords live in Settings → variables, but how you change one depends on the engine:

• Redis applies its password fresh on every start — it reads the variable each time it launches. Edit the Redis Password value, restart, and the new password is live: no reinstall, no data lost.
• MongoDB and PostgreSQL create their account when the application first installs, and the running engine keeps using that stored password — editing the variable afterward won't re-key an engine that's already installed. To change one without losing data, change it inside the engine itself (a 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.

Verify it works

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.

Troubleshooting

• Connection refused from another server — use the public address and port from the Network page, not localhost.
• It was working, now everything times out — on a free plan the database server's timer likely ran out and it stopped. Extend it on the Timer page, or move the data to a managed database so it can't sleep.
• Data gone after I changed something in Settings — switching the application or reinstalling wipes container files, and the engine's data lives in those files. A managed database is what survives that.
• Forgot the password — it's in the Settings variables (Redis Password, or the generated Mongo/Postgres credentials), not lost.

Next steps

• Add a managed database
• Connect your app to a database
• Keeping apps online