Run WordPress Without Managing a Server: The Practical Guide

Every WordPress guide written for our region starts the same way: rent a shared-hosting plan or a VPS, install a control panel, click through the famous five-minute installer, and then spend the next few years keeping a server alive. This guide takes the other path — building a WordPress site with no server to manage at all. WordPress runs as a container app built from a Docker image, its content lives in a managed MySQL database, and its media lives in S3-compatible object storage. It is written for business owners and developers in Syria and across the region who want a WordPress site that works, not a second job called server administration. Day one takes a little more thought than a one-click installer; in exchange, you never patch an operating system, renew a TLS certificate by hand, or wonder whether last night's backup actually ran. (If you are still weighing this against renting a VPS and running WordPress on it yourself, our VPS vs managed hosting comparison lays out that trade honestly.)

One promise before we begin: this is an honest guide, so it starts with the part most tutorials hide.

The honest part first: why a plain WordPress container will let you down#

On a modern app platform, the filesystem your app writes to is ephemeral. Every redeploy or restart starts from a clean copy of your Docker image, and anything written to the app's own disk since the last deploy is gone. WordPress, by tradition, assumes the exact opposite: it installs plugins into wp-content/plugins, saves every uploaded photo into wp-content/uploads, and expects those files to sit on the same disk forever.

Put those two facts together and the conclusion is plain, so we will state it plainly: a single-container WordPress that installs plugins through wp-admin and stores uploads on its own disk is not suited to this platform today. If you deploy the stock wordpress image as-is, install a theme from the dashboard, and redeploy a week later, that theme is gone. We would rather tell you this in the first section than let you discover it after your first redeploy.

The fix is not to fight the platform. It is to move each kind of state to the home where it belongs — and WordPress, for all its age, handles this arrangement very well.

The architecture that works#

Three pieces, each doing the one thing it is good at:

1. The code — WordPress core, your theme, and your plugins — is baked into a small custom Docker image. The image is the single source of truth for what runs on your site.
2. The content — posts, pages, settings, users, comments — lives in a managed MySQL database created in the portal. The platform runs it and backs it up.
3. The media — every image and file you upload — goes straight to S3-compatible object storage through a standard offload plugin, so files are stored durably and served independently of any single app instance.

Arranged like this, the app's disk holds nothing that matters. Redeploys are harmless, a crash recovers on its own, and your data never depends on one machine staying up.

Step 1: bake plugins and themes into the image#

Create a small Git repository containing a Dockerfile and the parts of wp-content you actually customise:

FROM wordpress:6.8-apache
 
# The site's code ships inside the image — nothing is installed live
COPY wp-content/themes/mytheme/  /usr/src/wordpress/wp-content/themes/mytheme/
COPY wp-content/plugins/         /usr/src/wordpress/wp-content/plugins/

The official image copies /usr/src/wordpress into place when the app starts, so everything you COPY there is present on every deploy. To add a plugin, download its zip from wordpress.org, unzip it into wp-content/plugins/, commit, rebuild, and redeploy. Yes, that is slower than clicking "Install" in wp-admin — the first time. In exchange, every deploy is reproducible: the same site, byte for byte, every time, with a one-step rollback (redeploy the previous image) if an update misbehaves.

Treat the image as the only way code reaches production, and switch off in-dashboard installs and file editors outright with one environment variable:

WORDPRESS_CONFIG_EXTRA=define('DISALLOW_FILE_MODS', true);

That single line also closes off a whole class of hacked-plugin attacks.

Step 2: create a managed MySQL database#

WordPress needs MySQL, and running a database yourself as a second app brings back exactly the state problem we just removed. Instead, create a managed MySQL database in the portal, inside the same project as your app. The platform provisions it in your project's isolated environment, operates it, and backs it up; you never install, patch, or tune a database server.

When it is ready, the portal gives you the connection credentials — host, user, password, and database name. Link the database to your app so the credentials arrive as environment variables, or copy them and set the variables yourself in the next step.

Step 3: point WordPress at the database#

The official WordPress image reads its database settings from environment variables at startup and writes wp-config.php for you — no file editing required. On your app, set:

WORDPRESS_DB_HOST=<database host>
WORDPRESS_DB_USER=<database user>
WORDPRESS_DB_PASSWORD=<database password>
WORDPRESS_DB_NAME=<database name>

Because configuration comes from the environment rather than from a file baked into the image, the same image can serve a test site and the production site, with nothing changing between them but the variables.

Step 4: send uploads to object storage#

The last piece of state is media. By default, WordPress writes uploads to its own disk, which on this architecture means they disappear on the next deploy. The standard fix is an offload plugin: it copies every media file to S3-compatible storage the moment it enters the media library, and rewrites URLs so visitors load files from storage directly.

Pick any well-maintained S3 offload plugin and bake it into the image in step 1. Then create a bucket in the portal — the object storage page covers how the storage works — and pass the credentials as environment variables. The exact constant names depend on the plugin you chose, but the pattern is always the same; extend the WORDPRESS_CONFIG_EXTRA variable from step 1:

define('S3_UPLOADS_BUCKET',   getenv('S3_BUCKET'));
define('S3_UPLOADS_ENDPOINT', getenv('S3_ENDPOINT'));
define('S3_UPLOADS_KEY',      getenv('S3_KEY'));
define('S3_UPLOADS_SECRET',   getenv('S3_SECRET'));

Storage costs $0.04 per GB a month with free outbound transfer, so a media library of a few gigabytes costs cents per month.

Step 5: deploy, then attach your own domain#

With the image built and the variables ready, deployment is the short part: open Cloud Studio in the portal, choose Application, point it at your image, and set the environment variables. Your site boots on a *.alawadi.cloud subdomain with HTTPS already working. Visit it once to run WordPress's famous installer — its answers are written to the managed database, so they survive every redeploy from now on.

Then move to your real address: add your custom domain on the app's page, point the DNS record the portal shows you, and the TLS certificate for your domain is issued and renewed automatically. A custom domain costs $0.17 per hostname a month. The broader deploy workflow — including deploying straight from a Git repository — is covered on our hosting page.

Updating the site without fear#

The daily work of running the site changes less than you might think. Writing posts, editing pages, moderating comments, changing settings — all of that lives in the managed database and behaves exactly as it always has. Uploading images works normally too; they simply land in object storage instead of on a disk that will not survive the next deploy.

What changes is code updates. Updating a plugin, a theme, or WordPress itself means updating the files in your repository, rebuilding the image, and redeploying. That discipline is the price of this architecture — and its reward, because for the first time you can test an update before your visitors ever see it, and undo it in one step if it goes wrong.

What it costs, and how to start#

Everything here is pay-as-you-go: the app and the managed MySQL database are metered by the hour, storage is $0.04 per GB a month, and a custom domain is $0.17 per hostname a month. Prices display in the currency you choose — US dollars, Syrian pounds, dirhams (AED), or Jordanian dinars. Build an estimate for your exact setup on the pricing page.

Starting costs nothing: sign in and claim the free $5 trial credit — no card needed — which is plenty to build and test this whole setup end to end. When you top up, the currently available rail is prepaid vouchers priced in Syrian pounds; card and cryptocurrency top-ups are not currently available. Your site runs today from our live region in the UAE; Syria is the next planned region, with Jordan to follow, and we label both "coming soon" until they genuinely serve traffic.

Run WordPress this way and you keep the parts of it you love — the editor, the flexibility, the plugin ecosystem — while the part you never loved, the server, stops being your problem. Questions while setting up? Open a support ticket in the portal or email [email protected].