Site files
Add or import an existing site
CMS solution
WordPress local development environment with FlyEnv
Build, import, and manage WordPress sites with the PHP version, extensions, database, web server, local domain, and HTTPS each site needs.
What FlyEnv manages for each WordPress site
WordPress is site-centric: the files, document root, PHP runtime, database, and local URL need to stay aligned. FlyEnv keeps PHP versions and extensions attached to each project.
PHP runtime
Choose the version per project
PHP extensions
Inspect and install extensions visually
Site database
Manage content and settings locally
Web server
Serve permalinks and local rewrites
Site URL
Test cookies, redirects, and webhooks
Optional services
Enable object cache or theme tooling only when needed
Multiple WordPress sites, one workspace
Keep client sites, plugin work, and theme development separate without rebuilding the local stack each time.
Per-site PHP version
Keep plugin and theme compatibility tied to the project runtime.
Separate site database
Manage MySQL or MariaDB without mixing client data between projects.
Clear document root
Reduce accidental exposure by making the served WordPress directory explicit.
Local domain and HTTPS
Test redirects, cookies, OAuth callbacks, and secure browser features locally.
A WordPress site workflow in FlyEnv
Move from project files to a working local site: choose the runtime, connect the database, set the served root, and develop themes or plugins on a real local URL.
- 1
Create or import
Start from a new project or an existing site directory.
- 2
PHP + extensions
Match the runtime to the plugins and themes.
- 3
MySQL / MariaDB
Attach the database that holds site content.
- 4
Set site root
Keep wp-config.php and wp-content/ in the served directory.
- 5
Local domain + HTTPS
Use client-site.test with a trusted certificate.
- 6
Theme / plugin development
Develop themes and plugins within wp-content/themes and wp-content/plugins.
Optional supporting services
Redis object cache
Optional object cache for sites whose caching setup uses Redis.
Node.js tooling
Add for theme or block tooling that requires a build step.
Why use FlyEnv for WordPress development
A more predictable local workflow for sites that depend on PHP, content files, databases, and browser-facing URLs.
Match PHP to the site
Use a compatible PHP version for legacy plugins, modern block themes, or a client site.
Legacy site → PHP 7.4 · Modern site → PHP 8.2+
See extension requirements
Check the PHP extensions a site needs before a plugin or import fails.
PHP → Extensions → verify before debugging
Choose MySQL or MariaDB
Keep the database engine close to the project instead of sharing one opaque stack.
Use the engine your site expects
Keep site roots separate
Give every WordPress site an explicit directory and local URL.
Use real local HTTPS
Test login cookies, redirects, payment callbacks, and embedded content on a trusted domain.
https://client-site.test
Start supporting services together
Use a Startup Group when a site needs PHP, its database, Redis, or frontend tooling at the same time.
Start a new WordPress site or bring an existing one local
Use FlyEnv for a fresh site, an existing client project, or a theme and plugin workspace you already have.
Create a new WordPress site
- 1Open PHP → New Project and choose WordPress.
- 2Choose the PHP version and Composer version used by the project.
- 3Create the project files and add the matching local site.
- 4Select the document root and configure the local domain.
- 5Start the site with its database and open it over HTTPS.
Import an existing site
- 1Open the existing WordPress directory.
- 2Set the PHP version and check required extensions.
- 3Create or connect the MySQL or MariaDB database.
- 4Add the site root, local domain, rewrite behavior, and HTTPS.
- 5Group the site services for a repeatable local start.
Compare local WordPress approaches
Different setups solve different problems. Here is what changes when WordPress runs in a manual stack, containers, or FlyEnv.
| Feature | Manual local stack | Container workflow | FlyEnv |
|---|---|---|---|
| PHP version isolation | Manual switching | Defined in container config | Per-project runtime selection |
| PHP extensions | Edit php.ini by hand | Rebuild image or config | Visual extension management |
| Multiple sites | Manual virtual hosts | One stack per project | Managed local sites in one workspace |
| Database lifecycle | Separate server setup | Container service | MySQL or MariaDB modules |
| Local HTTPS | Manual certificates | Proxy-specific setup | Trusted local domains and HTTPS |
WordPress FAQ
Common questions about using FlyEnv for local WordPress sites.
Can different WordPress sites use different PHP versions?
Yes. FlyEnv lets each project or local site use the PHP version it needs, which is useful when older plugins or themes are not ready for a newer runtime.
Can I use MariaDB instead of MySQL?
Yes. FlyEnv provides both database modules. Choose the engine that matches the site or the environment you want to reproduce locally.
Where should the local site point?
Point the site at the directory that contains the WordPress files and wp-config.php. Keep the served root explicit so private project files are not exposed accidentally.
Do I need Redis for every WordPress site?
No. Redis is optional and is useful when the site or its caching setup uses object caching. Start it only for the projects that need it.
Can I develop themes or blocks that use Node.js?
Yes. Add Node.js when the selected theme, block, or frontend tooling requires a build step. WordPress itself does not need Node.js to serve requests.
Can I manage several client WordPress sites in FlyEnv?
Yes. Keep their directories, PHP versions, databases, local domains, and optional services separate while managing them from one workspace.
Related solutions
Ready to build WordPress locally?
Run the site runtime, database, local domain, and HTTPS in one workspace.
Have questions using FlyEnv?