Tips on using LocalWP sandboxing

LocalWP, known as Local and formerly Local by Flywheel, is a free, user-friendly and popular sandbox hosting environment for developing WordPress sites.

Local sandboxes run directly on your workstations and are generally isolated to each machine as opposed to being available on the Internet. They also bundle useful features for site installation, migration, database administration, command line tools, and more.

Flywheel was acquired by WP Engine in June 2019 and Local began offering synchronization features with WP Engine sites in February 2020. WP Engine also made Local Pro features available to everybody for free starting in June 2021.

After working with many local hosting environments including Docker, VVV, XAMPP, MAMP, Homebrew; I must say this one is the most useful for WordPress sites. I’ll provide some pro tips based on how I like to use it:

• WP-CLI (WordPress command line) tools are available by right-clicking on a site name in the Local App and choosing Open Site Shell. I often run wp search-replace OLDURL NEWURL to change domains and protocols after importing databases.
• A SQL backup file is created whenever a site is stopped. This is a handy file to copy as a backup, especially before deleting a site from your list. It’s stored in the file Local Sites > [site] > app > sql > local.sql
  • When restoring a SQL file to LocalWP you may first need to run SET GLOBAL SQL_MODE ='ALLOW_INVALID_DATES';
• Sometimes you need PhpMyAdmin instead of the built-in Adminer database tool. Download PhpMyAdmin, install it into its own folder within your site’s app/public/ folder, access it from the browser and use credentials root / root to login. Easy!
• You can change your configurations inside your Local Sites folder by clicking on the site’s folder and the conf folder within. Restart the site after making changes. Use your computer’s Activity Monitor App to keep an eye on CPU and RAM utilization.
  • Routing images from production can be very useful when you don’t want to cache gigabytes on your workstation. This setup varies between Apache and Nginx.
    • Nginx rewrite for your site.conf file: location @production { resolver 8.8.8.8; proxy_pass https://mysite.com/$uri; } then append try_files $uri $uri/ @production; to the bottom of your image and font file extension location {} definitions.
    • If Cloudflare in production is blocking rewrites you can setup a 301 redirect instead: rewrite ^/wp-content/uploads/(.*)/(.*)/(.*)$ https://mysite.com/$1/$2/$3 permanent; into your server {} declaration.
  • MySQL is tuned for very low memory. For larger databases such as sites with lots of order history you should edit the my.cnf file and change innodb_buffer_pool_size from 32M (default 128M) up to half of your total RAM.
  • PHP-FPM is tuned for low activity with two workers. For more active sandboxes such as those running a lot of AJAX requests you can change your www.conf file to use the ondemand process manager and bump max_children to an appropriate number. For example with 8GB of RAM you can set it up to 8GB / 2 = 4GB / 75M per request memory footprint = 50 (rounded down) maximum child processes.