The setup work you no longer do
Standing up a database normally means provisioning a server, installing the engine, creating users and grants, tuning connection limits, opening the right ports, and keeping the whole thing patched. For a single app that is a lot of undifferentiated work before you write a line of business logic. cdn.com.tr provisions the MySQL, MariaDB, PostgreSQL, or Redis instance for you and hands back ready-to-use credentials, so you skip straight to connecting your application.
Credentials as environment, not as code
The platform generates the username and password and injects host, port, database, user, and password into the attached app as environment variables. This matters for security and for operations: secrets never sit in your Git history or your Docker image, and because the app reads them at runtime, rotating a password is a binding update rather than a code change. It keeps the twelve-factor separation of config from code without you building the plumbing.
Choosing between MySQL, MariaDB, and PostgreSQL
Most WordPress and classic PHP stacks expect MySQL or its drop-in cousin MariaDB, and either is a safe default for those apps. PostgreSQL is the right pick when your framework or schema relies on Postgres-specific types, extensions, or stricter SQL behavior. Because all three are offered as managed add-ons with the same attach-and-inject flow, the decision is about what your application expects, not about how hard each one is to operate — they are all provisioned the same way.
What managed Redis is actually for
Redis is an in-memory store, and on the platform it typically does one of three jobs: caching expensive query results and rendered fragments, holding user sessions so they survive across container replicas, and acting as a WordPress object cache to cut repeated database hits on busy pages. Because it lives outside the app container, a scaled-out service shares one cache and one session store instead of each replica keeping its own. That is what makes horizontal scaling behave correctly for stateful-feeling features.
Redis object cache for WordPress
A WordPress site under load spends a surprising amount of time re-running the same database queries to build every page. Pointing WordPress at a managed Redis add-on as its object cache means those results are served from memory instead of the database, which lowers query pressure and steadies response times when traffic spikes during a campaign. Paired with CDN cache for static assets, Redis handles the dynamic side so the database is not the bottleneck.
Rotation, reset, and shared use
Passwords should not be forever, and sometimes one leaks into a log or a screenshot. The reset/rotate flow generates a fresh credential and the attached applications receive it through their binding, so you are not chasing a hardcoded password across several codebases. When multiple services genuinely share a database, attaching the same add-on to each keeps them consistent, while platform status gives you a single place to confirm the data layer is healthy after any change.
How to set it up, step by step
Pick the engine your app needs
In the panel open the Add-ons area and create a database. Choose MySQL or MariaDB for most PHP and WordPress workloads, or PostgreSQL for apps that expect Postgres features. For caching, sessions, or a WordPress object cache, create a Redis add-on. Each one is provisioned for you with a database name, user, and generated password.
Attach it to an application
From the add-on or from the app's own settings, attach the database to a Container App, PHP Platform, or WordPress site. Attaching wires the connection details into the app rather than making you copy them by hand, and the same add-on can be shared by the services that legitimately need it.
Read credentials from the environment
Once attached, host, port, database name, username, and password arrive as environment variables in the app. Your code reads them at runtime — for example a PDO DSN or a Redis client built from those env vars — so nothing sensitive is baked into the image or committed to the repo.
Let WordPress and PHP wire themselves
For a WordPress site the platform fills the database connection during setup so you do not hand-edit wp-config, and a Redis add-on can back the object cache. For a custom PHP app, point your framework's database and cache config at the injected env names and you are connected.
Rotate or reset when needed
If a credential is exposed or you simply rotate on a schedule, use the reset/rotate flow on the add-on. A new password is generated and the attached apps pick up the updated value through their binding, so rotation does not mean a manual redeploy hunt across services.
Watch health and automate with cdnctl
Use platform status to confirm the add-on is up and reachable, and drive routine tasks — creating an add-on, attaching it, triggering a rotate — from cdnctl so environment provisioning fits into scripts and CI instead of manual clicks.
Example scenarios
A content site is provisioned with a managed MySQL database at setup and a Redis add-on as its object cache, so pages render from memory and survive traffic spikes without hammering the database.
A Laravel API attaches a managed PostgreSQL add-on and a Redis add-on for queues and cache, reading both connection sets from injected environment variables with no server administration.
A container app scaled to several replicas stores sessions in managed Redis so a user stays logged in regardless of which replica serves the next request.
A team rotates its database password from the panel each quarter; the attached apps receive the new secret through their binding, avoiding a manual sweep of config files.
Frequently asked questions
Which database engines can I provision?
MySQL, MariaDB, and PostgreSQL are available as managed database add-ons, and Redis is available as a managed cache add-on. Pick MySQL or MariaDB for typical WordPress and PHP apps, and PostgreSQL when your application specifically expects Postgres.
How does my app receive the connection details?
When you attach an add-on to an app, the host, port, database name, username, and password are injected as environment variables. Your code builds its DSN or Redis client from those variables at runtime, so no credentials live in the image or the repo.
Is Redis a database replacement or a cache?
It is a cache and in-memory store, not a replacement for your primary database. Use it for query and fragment caching, sessions that must be shared across replicas, and as a WordPress object cache — while your durable data stays in MySQL, MariaDB, or Postgres.
How do I rotate a database password without breaking apps?
Use the reset/rotate flow on the add-on. A new password is generated and the attached applications pick it up through their binding, so you do not have to edit config in each codebase. Confirm health afterward via platform status.
Can several apps share one database or Redis instance?
Yes. Attach the same add-on to each service that legitimately needs it and they share the instance and stay consistent. For isolation, provision a separate add-on per app instead — both patterns use the same attach-and-inject flow.
Does WordPress need manual database configuration?
No. The platform fills the database connection during WordPress setup, so you do not hand-edit wp-config for it, and a Redis add-on can be wired in as the object cache to reduce repeated database queries on busy pages.