"Code up, content down" is advice WordPress teams have given each other for years. Code moves up from your development, through staging, and into production. Content moves down from production into your local environment. Never the other way around.
On most hosting platforms, that is a rule your team has to keep. WordPress itself will happily break it for you. It installs plugins by writing them into wp-content, updates itself by overwriting its own core files, and lets an administrator edit theme code from inside the dashboard. One urgent fix applied through WP Admin at 2am, and production no longer matches the repository. Nothing tells you. You find out weeks later, when a deployment overwrites the fix or a new environment behaves differently than the old one.
Autoscale makes the rule structural. The code your site runs is built once and mounted read-only on every pod, so there is no writable copy for anyone to change.
The tradeoff is worth stating plainly. You give up making code changes from inside WordPress. In exchange, every line of code running on your site has a commit behind it. You can read it, review it, revert it, and reproduce it in another environment. Drift between environments stops being something you manage and starts being something that cannot happen. The same is true of an attacker, who cannot write code to a site that has nowhere to write code.
This page explains what changes, what does not, and what replaces the behavior you are used to. For why the platform is built this way, see Architecture.
What a read-only filesystem prevents
Section titled “What a read-only filesystem prevents”Most WordPress compromises end the same way. The attacker writes a file: a backdoor dropped into wp-content, a modified core file, a few lines added to a theme's functions.php. Whatever the way in, persistence almost always means getting code onto disk and getting it executed.
On Autoscale that step fails. The code directory is read-only, so the write does not succeed. /wp-content/uploads/ is writable, but files there are never executed, so it is not a substitute. Pods are replaced routinely, so anything an attacker holds in the memory of one pod goes away with it.
This is different in kind from the protections at the edge. A web application firewall and bot management work by recognizing malicious traffic before it arrives, which means they can be evaded by traffic they do not recognize. A read-only filesystem does not need to recognize anything. The capability the attack depends on is not there.
Two related benefits come from the same arrangement. Code cannot change without a commit, so a malicious plugin update cannot arrive quietly. And because your site runs a specific built image, recovering from a compromise is a redeploy of a known-good version rather than an audit of a filesystem you can no longer trust.
What stays the same
Section titled “What stays the same”Most of WordPress is unaffected, because most of WordPress lives in the database rather than on disk.
Posts, pages, custom post types, taxonomies, comments, menus, widgets, users and roles, permalinks, and plugin settings all behave exactly as they would anywhere else. Editing content, configuring a plugin, or changing a setting writes to the database, and the database is fully writable.
Uploading media through WP Admin also works normally. WP Engine provides an integration that routes uploads to shared storage rather than to a pod's local disk, so the media library behaves the way authors expect.
What changes in WP Admin
Section titled “What changes in WP Admin”Four things in the dashboard work differently, and all four are cases where WordPress would otherwise write to the code directory.
Installing plugins and themes
Section titled “Installing plugins and themes”The installer cannot add code to a running site. Plugins and themes come from your repository and reach the site through a deployment.
Updating plugins and themes
Section titled “Updating plugins and themes”Same reason, same answer. You update the version in your repository and deploy, which means every update is a reviewable change with a commit behind it.
Editing theme and plugin files
Section titled “Editing theme and plugin files”The built-in file editors are not available. Edit locally, commit, and deploy.
Updating WordPress core
Section titled “Updating WordPress core”WP Engine manages core, and core files are mounted separately from your code. You do not update core from the dashboard, and core files should never be in your repository. There is also no need to choose a preferred update source for an Autoscale account, since neither core nor your plugins update through WordPress itself.
SFTP is not available on Autoscale environments.
An SFTP session exists to move files onto a server and change them in place, which is the one thing the platform is built to prevent. There is also no single server to connect to. Your site runs on however many pods traffic currently requires, each one a copy of the same image, so a file placed on one of them would not exist on the others and would disappear the moment that pod was replaced.
Everything SFTP is normally used for has another route on Autoscale. Code changes go through your repository and a deployment. Everything else, including moving media in bulk, importing a database, and inspecting the running site, goes through SSH.
SSH and WP-CLI
Section titled “SSH and WP-CLI”SSH access does exist on Autoscale, and WP-CLI is available through it.
What changes is what you can do once you are connected. The filesystem is read-only apart from /wp-content/uploads/, and that applies to WP-CLI exactly as it applies to everything else. Any command that writes outside the uploads directory fails.
In practice this splits WP-CLI cleanly in two.
Commands that read or write the database work normally. Managing posts, users, options, terms, and metadata, running search and replace, exporting and importing content, flushing the object cache, and running database queries all behave as they would on any other WP Engine environment. This is the majority of what WP-CLI is used for day to day.
Commands that write code to disk do not work. Installing, updating, or deleting plugins and themes, updating core, and scaffolding new files all need to write into the code directory. Those operations belong to your repository and your build, so the answer is the same as it is in WP Admin: make the change in Git and deploy it.
A useful rule of thumb is that if a WP-CLI command would change what is in your repository, it is not the right tool on Autoscale. If it changes what is in your database, it works.
SSH is also what replaces SFTP for bulk transfers. Because /wp-content/uploads/ is writable and the database is fully available, an existing media library can be moved in over SSH, and a database too large for the migration plugin can be imported the same way. Neither touches code, so neither is affected by the read-only filesystem.
Where WordPress can write
Section titled “Where WordPress can write”/wp-content/uploads/ is the only writable path, and it is shared storage rather than pod-local disk, so anything written there is immediately visible to every pod and survives them.
Two consequences catch people out:
Uploads do not appear in your repository. Media uploaded through the dashboard goes to shared storage, not to Git. Your repository holds code; the platform holds content. Trying to keep media in the repository is not necessary and will not work.
Files in uploads are never executed. A PHP file written into uploads/ will be served as a file, not run as code. That is what keeps the one writable path from becoming a way around everything else, and it means uploads/ is not an escape hatch for plugins that want somewhere to write executable code.
Plugins that need configuration
Section titled “Plugins that need configuration”Plugins that only read from disk and write to the database work without changes. Plugins that expect to write files into the install need configuration, and they fall into three groups.
Page caching plugins generate static HTML or a drop-in file inside wp-content. On Autoscale, page caching happens at the Cloudflare edge instead, so most of these plugins are redundant.
Backup plugins write archives into the install directory. Autoscale backs up the database, the uploads directory, and the exact image your site is running, which together restore the full state of the site, so a plugin-based backup has nothing to add.
Security scanners quarantine files, write signature databases, or update themselves in place. The behaviors they rely on are the same ones the read-only filesystem prevents. They are also largely looking for a threat the platform has already removed, as covered in what a read-only filesystem prevents.
For the current list of WP Engine products and third-party features that need extra setup or are not supported, along with their alternatives, see the compatibility reference.
Moving content between environments
Section titled “Moving content between environments”Push and pull between development, staging, and production carry the database and the uploads directory. They do not carry code, because code is not part of the environment in the way it is on a traditional install.
Code moves between environments by branch. You point each environment's pipeline at the branch that should deploy to it, and promoting a change means merging it into the next branch rather than copying files from one server to another.
The same applies to migrations. The WP Engine Site Migration plugin brings the database and media into an Autoscale site. Themes and plugins come in through your repository and your first deployment.
The short version
Section titled “The short version”If it lives in the database or the media library, it works the way you expect. If it writes code to disk, it goes through Git. Almost every WordPress behavior that changes on Autoscale is an instance of that rule.
Read as a list, the changes look like features removed. Read together, they are the same feature: your repository is the only source of code your site can run. That is the arrangement most WordPress teams already want and spend real effort trying to hold in place. On Autoscale it holds itself.