Roots Discourse

Local Bedrock Development with Local by Flywheel

Originally published at:

While there are many fantastic tools for developing with WordPress (and other things) locally, I’ve found that some developers might be a little bit weary to use the command line at all times. Personally, I love GUIs and find them to be a little easier to use as long as they can be lightweight. Local…


@JulienMelissas, thanks a lot - very clear info - I hacked about with Docker from scratch for ages, but could never get SSL to work…

Do you find your Flywheel site is more responsive/faster than Vagrant?

How did you decide on Flywheel BTW? Did you consider Devilbox for example?

Sounds like it would be fairly simple to migrate an existing site from local Trellis/Vagrant to this setup, or are there any gotchas?

1 Like

Do you find your Flywheel site is more responsive/faster than Vagrant?

I moved off of Vagrant a long time ago. WAYYYY too slow.

How did you decide on Flywheel BTW? Did you consider Devilbox for example?

I decided on Flywheel because it looked easy to use, I tried it, and it worked quickly for me and my other devs. No other big reason. I like that it’s well supported in the WP world. Lando looks cool too.

Sounds like it would be fairly simple to migrate an existing site from local Trellis/Vagrant to this setup, or are there any gotchas?

I don’t think it would be difficult to migrate from existing Trellis / Vagrant setup. Make a new site, follow my instructions or just clone the existing Bedrock repo in in place of my composer create-project command, and move the DB and you should be fine.

EDIT: it should take you less than an hour to try it out. I’d suggest just trying it and seeing how you like it. I’d also suggest checking out Lando:


This is awesome- thanks for putting it together.

I’ve tried today with a new install of everything (Local is now v3.0.4) and unfortunately it doesn’t seem to work. Based on the logs from Local (below) I am guessing this is why:

Feb 7, 2019, 5:21 PM PST - warn: [main/SiteModel] wpInstalled not returning "installed" 
{ stdout: '',
   'Error: This does not seem to be a WordPress install.\nPass --path=`path/to/wordpress` or run `wp core download`.' }

Strangely- after leaving it for a few minutes, it worked? I had previously done a restart a couple of times as well.

1 Like

Weird. Yeah I’ve never encountered that error, but glad you figured it out!

This topic was automatically closed after 42 days. New replies are no longer allowed.

Hey just as a quick update here - I’ll try and get the guide updated when I can, but if you are using the new version of Local (Lightning?), you may have to provide the full path to your webroot.

See this tweet:

That worked for me, thank you!!

1 Like

Seems this process works fine for linux and macOS users however, for windows its spitting out 404 error. The nginx file is named site.conf.hbs on local by flywheel and the root is pointing to root “{{root}}”; am i missing something?

Hey @Alfred_Smart - unfortunately I don’t have Windows so I can’t look for myself. I’d suggest reaching out to the Local by Flywheel folks and asking them about that! Sorry I can’t be more helpful.

@Alfred_Smart If you haven’t already done this, you need to print the full path for root instead of using {{root}}. I’m not sure what the windows equivalent is, but on a mac I would replace {{root}} with the output of pwd from the web directory.

Local has a discourse which might be another place to get help on this.

On Windows, the line should look like this (obviously edited for your own environment):

root "C:\Users\ethan\Local Sites\principleaccounting\app\principle-accounting\web";

However, I’m having an issue with the latest Local where this setting isn’t used for the SSH path, so every time I try to SSH into my Local site, it tells me directory not found. It’s still looking for the old public folder.

cd: /c/Users/Ethan/Local Sites/principleaccounting/app/public: No such file or directory

I get everything to work locally (on mac) but it doesn’t push up to flywheel after the change to bedrock.
" Uh-oh! We ran into an issue when pushing this site to Flywheel.

Do you successfully push through wp local?

Here’s what it says in my logs:
2021/02/28 16:37:30 [error] 4053#0: *49 FastCGI sent in stderr: “PHP message: Xdebug: [Step Debug] Could not connect to debugging client. Tried: ::1:9000 (from HTTP_X_FORWARDED_FOR HTTP header), localhost:9000 (fallback through xdebug.client_host/xdebug.client_port) :-(” while reading upstream, client:, server: , request: “GET /wp-admin/?cache-buster=1688 HTTP/1.0”, upstream: “fastcgi://unix:/Users/kalwiggins/Library/Application Support/Local/run/ICM9oHu4g/php/php-fpm.socket:”, host: “epictestfive.local”

Hey @Kal_Wiggins - sorry for the late reply. I have never tried to push up to Flywheel, but based on the error that looks like a xdebug error. I’d ask the Flywheel team about this!

FYI, you shouldn’t be pushing the local theme files as they include development-specific packages.
Consider a Continuous Integration services (I personally use bitbucket pipelines) to build and deploy a production version of the theme.
Not sure if Sage is compatible with flywheel though. I use it locally but deploy to Kinsta.

1 Like

@JulienMelissas a great addition to this guide would be using WP CLI from outside flywheel like we’re used to with trellis.
It’s available to Mac and Linux as you can see in this guide except for using the database socket instead of db host and port that were available in older versions of Local.
so it’d be something like

define('DB_HOST', 'localhost:/home/user/.config/Local/run/Sc6$DXLNK/mysql/mysqld.sock');

instead of

define('DB_HOST', '');

This allows using wp option get siteurl anywhere from the project’s root, and setting @production alias allows for using the sync script and a lot of functionalities similar what Trellis is offering.


Very nice! Thank you.

I think this step is unnecessary with lates version of Flywheel:

The current Local configs are .hbs files, which seem to contain variables.

server {
    listen {{port}};
    root   "{{root}}";

And my bedrock site is running nicely in the browser without any updates to that file.