Automated WordPress
Automated runs the WordPress code supplied by your project. Edit posts, pages, and settings in WP Admin. To change WordPress itself, themes, or plugins, update your project and deploy a new version.
For database ownership, domains, and required environment variables, see Shared settings.
Prepare your project
Section titled “Prepare your project”Your project supplies WordPress, PHP, extensions, the web server, and the initial admin account. Composer-based projects such as Bedrock are supported. FrankenPHP is optional.
Building with Railpack
Section titled “Building with Railpack”For Git sources, Root & Branch Cloud uses Railpack to turn your project into a container image. Railpack detects the project, prepares dependencies and build commands, and defines how the image starts. The platform then deploys that image.
If the detected build does not suit your project, add or update railpack.json. It can customise build steps, packages, and the startup command.
- Check the failed build step in Activity.
- Place
railpack.jsonin the project directory selected for the build. For a subdirectory project, this is not necessarily the repository root. - Adjust the configuration, commit it, and push. Rebuild through auto-deploy or trigger a deployment manually.
See the Railpack configuration reference for supported fields and examples. Use the build error to guide changes; railpack.json cannot fix invalid repository credentials or application code errors by itself.
Runtime requirements
Section titled “Runtime requirements”Before deploying, check that your app or image serves HTTP on port 80.
Create your site
Section titled “Create your site”- Open Apps → New App → WordPress and choose Automated (Git + CI/CD).
- Enter a name and choose a source.
- Choose app resources, database resources, database storage, and uploads storage.
- Click Review, then Deploy App. Follow progress in Activity.
| Source | Setup |
|---|---|
| GitHub, GitLab, or Bitbucket | Connect one provider and select a repository. Defaults: branch main, project directory /. Railpack builds the image. |
| Docker Image | Supply a ready-to-run image. Private images also need registry server, username, and password. The platform skips the build step. |
The platform provides MySQL 8.4.9 and a separate Varnish 7.5 page cache.
Deploy updates
Section titled “Deploy updates”Git: push changes to the selected branch. With Auto-deploy enabled, the platform builds and deploys them automatically. Otherwise, trigger deployment from the dashboard.
Docker: publish the updated image, then deploy it from the app settings.
Files and storage
Section titled “Files and storage”Media uploads
Section titled “Media uploads”Uploads volume keeps media across deployments. It is enabled by default in the dashboard and starts at 2 GiB.
| Setting | What to use |
|---|---|
| Size | Enough space for the media library |
| Mount path | The image’s uploads directory; /app/web/app/uploads for the default Bedrock layout |
| External storage | Turn off the volume only if the project already sends uploads to storage such as S3 |
The mount path must be absolute and cannot be /. The platform does not install an offload plugin or supply bucket credentials.
Temporary files
Section titled “Temporary files”/tmp provides 128 MiB of memory-backed storage. It counts towards app memory and is cleared when the running instance is replaced.
- Use it for disposable files, not media you need to keep.
- Increasing app memory does not increase the
/tmpsize limit. - Plugins that write caches, sessions, or generated files need a writable path or external service.
Runtime defaults: XDG_DATA_HOME=/tmp/.local/share and XDG_CONFIG_HOME=/tmp/.config.
Configure your site
Section titled “Configure your site”| Change | Where | How it takes effect |
|---|---|---|
| PHP, WordPress, or web server settings | Source project / image | Rebuild and deploy |
| Railpack build steps and image startup | railpack.json in the selected project directory |
Next Git build |
| Runtime settings and credentials | Environment | App restart; no rebuild |
| Build variables | Build configuration | Next Git build |
| Page caching rules | Config → Varnish | Varnish restart only |
Saved Varnish rules survive redeployment. Keep backend default host and port unchanged. Files must be non-empty and at most 1 MiB. Validation protects the backend settings but does not compile the full VCL file.
Environment and URLs
Section titled “Environment and URLs”The platform generates the required system variables. They are reserved during creation; configure your project to read them.
| Variable | Default |
|---|---|
WP_ENV |
production; required in Automated mode |
WP_HOME |
https://<primary-domain> |
WP_SITEURL |
https://<primary-domain>/wp |
Support the /wp core layout and forwarded HTTPS headers. Domain changes update both URL variables. They do not replace old URLs stored in database content.
Scheduled tasks
Section titled “Scheduled tasks”The default trigger calls /wp-cron.php?doing_wp_cron every five minutes. Jobs do not overlap.
If core is under /wp, provide a route to that endpoint or have the trigger changed to /wp/wp-cron.php?doing_wp_cron. The trigger path is not editable in Config.
Set DISABLE_WP_CRON=true in your project to prevent page visits from also triggering cron.
Troubleshooting
Section titled “Troubleshooting”| Problem | First checks |
|---|---|
| Site is down or deployment is stuck or keeps restarting. | Check MySQL status, then the app’s memory and disk usage. If either has reached its limit, increase that component’s memory tier or persistent storage in its own Settings. App and database resources are separate. |
| Build fails | Check the failed step, provider connection, branch, project directory, dependencies, and build variables. Adjust railpack.json when the build configuration needs changing. Runtime variables are not automatically build inputs. |
| Image cannot start | Check image availability, registry credentials, startup logs, port 80, and attempted writes to read-only paths. |
| Uploads fail or disappear | Check the volume, capacity, mount path, and permissions. If using external storage, check its credentials and plugin configuration. |
| Read-only filesystem error | Change the failing plugin’s write path to /tmp, uploads storage, or an external backend. Install core and plugins in the image. |
| No space or memory termination | Check /tmp usage and total app memory separately. Temporary files consume memory, not uploads disk space. |
| Database, login, or redirect failure | Check MySQL status, DB_* values, salts, URL layout, and forwarded HTTPS. Non-empty credentials can still be wrong. |
| 503 after editing cache rules | Check Varnish logs, VCL syntax, and backend connection. Clearing the cache cannot fix invalid VCL. |
| Scheduled tasks do not run | Check the actual cron URL response, including the /wp prefix. A completed trigger job does not prove success. |
| Environment/config edit blocked | Check required variables, file limits, the protected backend, and active backup/restore operations. |
Technical reference for debugging
Use the app’s system name, not its display alias, for <app>. Existing deployments retain their installed chart version; current defaults are wordpress-immutable 1.2.0 and managed MySQL chart 1.1.4.
| Resource | Identifier / default |
|---|---|
| App deployment / container | <app> / app; image pull policy Always |
| Cache deployment / container | <app>-varnish / varnish |
| Optional uploads disk / environment | <app>-uploads / <app>-env-vars; build variables in <app>-build-env-vars |
| Configuration | <app>-varnish-config; deployment metadata in <app>-deploy |
| Database / scheduler | <app>-db / <app>-cron |
| Filesystem security | Root read-only, privilege escalation disabled, fsGroup=82; service-account token not mounted. |
| Chart-only defaults | tmpfs.sizeLimit=128Mi; cron.enabled=true, cron.schedule=*/5 * * * *, cron.path=/wp-cron.php?doing_wp_cron. Raw uploads size is 10Gi; the dashboard supplies its own size. |
Uploads use ReadWriteMany storage. Direct app creation without a persistence request does not provision an uploads disk.
The chart defines no readiness or liveness probe. Check an HTTP response as well as process status. Cron output is suppressed; HTTP errors alone do not fail the trigger job.
Request routing and caching
Section titled “Request routing and caching”Traffic follows: Traefik HTTPS → Varnish :80 → WordPress :80. Static /wp-content/ and /wp-includes/ routes also use Varnish.
| Cache setting | Default |
|---|---|
| Backend timeouts | First byte 600s; between bytes 60s |
| Fallback TTL | 120s |
| Cache key | URL, host, forwarded protocol; tracking parameters removed |
| Bypasses | Admin, login, cron, POST, logged-in requests |
| Uncached responses | Redirects and 5xx |
| Cache allocation | 128M |
| Resource requests | 10m CPU, 160Mi memory; no chart resource limits |
VARNISH_MEMORY is read at creation. Editing it in runtime environment alone does not resize the cache.
Compute and database
Section titled “Compute and database”App and database resource requests are 20% of CPU limits and 80% of memory limits.
MySQL runs one instance, with no Router and seven-day binary logs. Manage its resources from the database settings.
| Database memory | Connection limit |
|---|---|
| 1 GiB | 20 |
| 2 GiB | 50 |
| 4 GiB | 100 |
| 8 GiB | 200 |