Manual WordPress
Manual gives you a WordPress site you can update directly. Use WP Admin for content, themes, plugins, and core updates. Use SFTP or WP-CLI when you need file or command-line access.
For database ownership, domains, and required environment variables, see Shared settings.
Create your site
Section titled “Create your site”- Open Apps → New App → WordPress and choose Manual (WP Admin + SFTP).
- Enter a name and choose WordPress 7.0 (default) or 6.9.4.
- Set the admin credentials. The default username is
admin. Leave the password blank to generate one. - Choose resources and disk sizes for the app and database.
- Click Review, then Deploy App. Follow progress in Activity.
Once ready, sign in at https://<your-domain>/wp-admin/. A generated password is available as ADMIN_PASSWORD in Environment.
Update your site
Section titled “Update your site”Use WP Admin to update WordPress, themes, and plugins. WP-CLI is also available as wp in the app shell, with /var/www/html as its working directory.
Files and storage
Section titled “Files and storage”| Location | What it stores | Kept after redeployment? |
|---|---|---|
| WordPress disk | Core, themes, plugins, and uploads at /var/www/html. Starts at 1 GiB. |
Yes |
wp-config.php |
WordPress configuration, managed through Config → WordPress. | Yes |
/tmp |
Temporary files. No dedicated memory-backed volume or size limit. | No |
App restarts briefly interrupt the site. Changes to files outside persistent storage are lost when the running instance is replaced.
Connect with SFTP
Section titled “Connect with SFTP”Add your SSH public key in Settings → SSH / SFTP Access, then connect with:
| Setting | Value |
|---|---|
| Host | sftp.rootandbranch.io |
| Port | 2223 |
| Username | The app username shown in the connection instructions |
| Authentication | The matching private key; passwords are not supported |
wp-config.php is read-only through SFTP. Edit it in Config → WordPress.
Configure your site
Section titled “Configure your site”Open Config once the app is running. Saved settings survive redeployment.
| Change | Where | What restarts |
|---|---|---|
| Upload, PHP memory, or time limits | Config → PHP Uploads | WordPress |
| PHP code cache | Config → PHP OPcache | WordPress |
| WordPress settings | Config → WordPress | WordPress |
| Web server routing | Config → Caddy | WordPress |
| Page caching rules | Config → Varnish | WordPress and Varnish |
| Runtime variables | Environment | WordPress; no rebuild |
Uploads and PHP
Section titled “Uploads and PHP”Manual uses FrankenPHP with PHP 8.5.12. Caddy serves the site on port 80. MySQL 8.4.9 stores content, and Varnish 7.5 caches pages.
| Limit | Default | PHP setting |
|---|---|---|
| One uploaded file | 64 MB | upload_max_filesize |
| Entire upload request | 64 MB | post_max_size |
| Memory per script | 128 MB | memory_limit |
| Script execution time | 300 seconds | max_execution_time |
| Input processing time | 300 seconds | max_input_time |
Files sent together must fit within the request limit. Increasing the app’s resource tier does not change these PHP limits.
WordPress and web server
Section titled “WordPress and web server”WordPress configuration lives in wp-config.php. Keep its database, URL, key, and salt environment reads, HTTPS forwarding logic, and wp-settings.php bootstrap. See the required variables. Manual does not require WP_ENV.
Initial installation variables set up the site once. Editing them later does not change an existing account or site title.
| Variable | Initial value |
|---|---|
WORDPRESS_VERSION |
Selected WordPress version |
SITE_TITLE |
My WordPress Site |
ADMIN_USER |
admin, unless supplied |
ADMIN_PASSWORD |
Generated, unless supplied |
ADMIN_EMAIL |
admin@example.com, unless supplied |
Caddy configuration controls HTTP routing and FrankenPHP. Varnish configuration controls page caching. Keep Varnish’s backend default host and port unchanged.
Scheduled tasks
Section titled “Scheduled tasks”The platform calls /wp-cron.php?doing_wp_cron every five minutes. Jobs do not overlap. DISABLE_WP_CRON=true prevents page visits from also triggering cron.
The Manual schedule and path are fixed. Changing cron.* values has no effect.
Troubleshooting
Section titled “Troubleshooting”Start with Activity and the relevant service logs.
| 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. |
| Setup is stuck | Check wp-setup logs, outbound access for the core download, MySQL status, and all four DB_* values. The database wait retries every 2 seconds. |
| Site is not ready | Check the response from / and FrankenPHP logs. Startup copies PHP settings, installs mysqli, and starts Caddy. |
| Upload or plugin operation fails | Check disk space, permissions, upload limits, and PHP memory. wp-config.php is intentionally read-only. |
| Login or redirect loop | Check the primary domain, both WordPress URL variables, and forwarded HTTPS. Old URLs in database content need updating separately. |
| 503 after editing cache rules | Check Varnish logs and VCL syntax. Saving validates the backend connection settings, not the full VCL syntax. |
| Old content or code appears | Clear Settings → Varnish Cache. For PHP code, also check OPcache. |
| A configuration save is rejected | Check protected directives, the unchanged Varnish backend, and file size: non-empty, maximum 1 MiB. Wait for active backup/restore operations to finish. |
| Scheduled posts do not run | Check the cron URL response. A completed trigger job does not prove success: output is hidden and HTTP errors alone do not fail the job. |
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-mutable 1.0.4 and managed MySQL chart 1.1.4.
| Resource | Identifier |
|---|---|
| App deployment / containers | <app> / frankenphp; init container wp-setup |
| Cache deployment / container | <app>-varnish / varnish |
| Persistent disk / environment | <app>-pvc / <app>-env-vars |
| Configuration | <app>-wp-config, <app>-php-config, <app>-caddy-config, <app>-varnish-config; deployment metadata in <app>-deploy |
| Database / scheduler | <app>-db / <app>-cron |
Runtime defaults
Section titled “Runtime defaults”| Setting | Value |
|---|---|
| Storage / rollout | ReadWriteOnce; Recreate deployment strategy |
| Readiness | HTTP /; initial delay 5 seconds, interval 5 seconds |
| Caddy | SERVER_NAME=:80, SERVER_ROOT=/var/www/html; zstd, Brotli, gzip compression |
| WordPress | WP_DEBUG=false, FORCE_SSL_ADMIN=true, FS_METHOD=direct |
| Database encoding | DB_CHARSET=utf8mb4, empty DB_COLLATE, table prefix wp_ |
| Uploads | file_uploads=On |
| OPcache memory / strings | opcache.memory_consumption=128; opcache.interned_strings_buffer=8 MiB |
| OPcache scripts / checks | opcache.max_accelerated_files=4000; opcache.revalidate_freq=2 seconds |
| OPcache shutdown | opcache.fast_shutdown=1 |
PHP configuration files are uploads.ini and opcache-recommended.ini. PHP_FPM_MAX_CHILDREN is passed through but unused by the current FrankenPHP templates; it does not control concurrency.
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 |