dev was ~149 commits ahead of the last release with no changelog and several stale docs. This brings the user-facing docs in line with what actually ships. New: - CHANGELOG.md — curates the unreleased panel work (agent fleet, plugins, status pages, cloud provisioning, RHEL support, installer hardening). - agent/CHANGELOG.md — the agent release workflow links to this on every published release; it was a broken link. Now documents the agent's independent release line. - SECURITY.md — vulnerability reporting policy + agent trust model (agent.key is host-equivalent; Features.Exec off by default; single-worker). Fixes: - Stale version stamps: docs/README.md and docs/API.md said 0.9.0 -> 1.6.7. - Supported OS: README/INSTALLATION said Ubuntu/Debian only; installer also covers Fedora and RHEL/Rocky/AlmaLinux. - Dead links/placeholders: API.md wiki link, INSTALLATION.md "yourusername". - Windows agent + short-code pairing were undocumented; added to README, agent/README.md, and docs/pairing.md (incl. corrected host-stable credential-key derivation — USERNAME was dropped in agent 1.6.14). - Documented the single gevent-websocket-worker deployment constraint in CLAUDE.md and docs/ARCHITECTURE.md. - CONTRIBUTING.md: removed reference to a non-existent frontend test suite. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6.7 KiB
Multi-Environment WordPress Setup Guide
ServerKit supports multi-environment linking, allowing you to link production and development WordPress instances that share the same database with separate table prefixes.
Overview
What is Multi-Environment Linking?
Multi-environment linking allows you to:
- Create production and development versions of the same WordPress site
- Share the same database between environments (with different table prefixes)
- Quickly navigate between linked environments in the UI
- Maintain separate content, themes, and plugins for each environment
Use Case: WordPress Theme Development
A common workflow:
- Production WordPress serves live traffic with the stable theme
- Development WordPress uses the same database for content reference
- Develop and test new theme in dev without affecting production
- When ready, deploy theme changes to production
Quick Start
Step 1: Deploy Production WordPress
- Go to Applications > New Application
- Select the WordPress template
- Configure your production instance:
- Name:
my-site-prod(or your preferred name) - Port: Choose an available port
- Name:
- Click Install and wait for deployment
Step 2: Deploy Development WordPress
-
Go to Applications > New Application
-
Select WordPress (External Database) template
-
Configure your development instance:
- Name:
my-site-dev - Port: Different from production
- Name:
-
Enter the same database credentials as production:
- DB Host: Same as production
- DB Port: Usually
3306 - DB Name: Same database name
- DB User: Same database user
- DB Password: Same password
- Table Prefix:
wp_dev_(MUST be different from production)
-
Click Test Connection to verify database access
-
Click Install
Step 3: Link the Applications
- Navigate to your production app's detail page
- Find the Environment Linking section in the Overview tab
- Click Link App
- In the modal:
- Select your development app from the dropdown
- Choose Development as the environment type
- Keep "Propagate database credentials" enabled
- Click Link Apps
Step 4: Verify the Setup
After linking, you should see:
- PROD badge on your production app
- DEV badge on your development app
- Quick navigation buttons between linked apps
- Shared Database information displayed
Understanding Environment Types
| Type | Badge | Description |
|---|---|---|
| Production | Green PROD | Live/stable environment |
| Development | Blue DEV | Testing/development environment |
| Staging | Yellow STAGING | Pre-production testing |
| Standalone | None | Not linked to any environment |
Managing Linked Apps
Navigating Between Environments
In the Linked Apps section of any linked app:
- Click the arrow icon to navigate to the linked app
- Both apps are always one click away from each other
Unlinking Apps
To unlink apps:
- Go to either app's Settings tab
- Find the Environment Configuration section
- Click Unlink Application
- Confirm the action
Both apps will become "Standalone" and continue to function independently.
Changing Environment Type
For standalone (unlinked) apps:
- Go to the app's Settings tab
- Use the Environment Type dropdown
- Select the desired type
- Change is saved automatically
Note: Linked apps cannot change their environment type without unlinking first.
Filtering Apps by Environment
In the Applications list:
- Find the Environment filter dropdown in the toolbar
- Select an environment type to filter:
- All Environments - Show everything
- Production - Only production apps
- Development - Only development apps
- Staging - Only staging apps
- Standalone - Only unlinked apps
The filter persists in the URL for bookmarking.
Database Sharing Details
How Table Prefixes Work
When you install WordPress with an external database:
- Production uses:
wp_posts,wp_options, etc. - Development uses:
wp_dev_posts,wp_dev_options, etc.
Both installations:
- Share the same MySQL database
- Have completely separate WordPress data
- Can have different themes, plugins, and settings
Credential Propagation
When linking apps with "Propagate database credentials" enabled:
- Database host, name, user, and password are synchronized
- Table prefix remains unique to each environment
- Changes to credentials are not automatically synced (manual update needed)
Best Practices
Naming Conventions
- Use consistent naming:
mysite-prod,mysite-dev,mysite-staging - Include environment in the name for clarity
Table Prefixes
- Production:
wp_(default) - Development:
wp_dev_ - Staging:
wp_staging_
Backup Strategy
- Back up your database before major changes
- Each environment shares the database but has separate tables
- A database backup protects all environments
Theme Development Workflow
- Install and customize themes in development
- Test thoroughly with dev content
- When ready, manually copy theme files to production
- Or use your deployment tool to sync themes
Limitations
Not Yet Implemented
- Theme Sync: Automatic copying of themes between environments is planned for a future release
- Plugin Sync: Plugins must be installed separately in each environment
- Content Sync: Content is separate by design (different table prefixes)
Requirements
- Both apps must be the same type (WordPress to WordPress)
- Neither app can be already linked to another
- Database must be accessible from both app containers
- You must specify a unique table prefix for each environment
Troubleshooting
"No Compatible Apps" in Link Modal
- Ensure you have another WordPress app that is:
- Not already linked
- Set as "Standalone" environment
- Running (or at least created)
Database Connection Failed
- Verify MySQL is running and accessible
- Check firewall rules allow connections
- Confirm credentials are correct
- Try the Test Connection button before installing
Apps Show Wrong Environment
- Unlink the apps
- Re-link with correct environment assignments
- Only standalone apps can be linked
Can't Change Environment Type
- If the app is linked, you must unlink it first
- Only standalone apps can change their environment type
API Reference
For programmatic access, see the API Documentation.
Key endpoints:
POST /apps/{id}/link- Link two appsGET /apps/{id}/linked- Get linked appsDELETE /apps/{id}/link- Unlink appsPUT /apps/{id}/environment- Change environment typeGET /apps?environment=production- Filter by environment