Setting up a local test env without docker
I hit some snags around CSRF in the first attempt, and I know people have working local/native environments set up, let's take a second pass at this.
Last updated
Was this helpful?
I hit some snags around CSRF in the first attempt, and I know people have working local/native environments set up, let's take a second pass at this.
Last updated
Was this helpful?
First pass was but hit some snags, this is a "refresh/reset/rest" attempt to login to a local dev instance of forem using the admin password.
Trying to setup a local development environment following
Initial attempt followed but this pass will instead focus on
Ideally this resolves the request header did not match site url issue I was seeing (in which case that's an issue with the docker environment and should be fixed). Worst case is I see the same forgery protection running locally outside of a container and have to resolve that.
I already had postgresql and redis installed locally, but those need to be started, systemctl start postgresql and systemctl start redis_6379 seem to work for me locally (if you're using another init system, or have other names for your services that's fine). It's likely I'll want or need to setup postgres users for the database (or trust all local connections, I'm not telling you which is better, trusting all local connections disables usually works well for me, but a lot of applications insist on sending passwords so you might want or need to add the user in the database url for the forem development env, I'll see what happens later).
Debian 10 has redis 5.0.3 (which is what redis-server --version printed when I asked and what apt search redis suggested was current), but forem requires redis 6.0 or higher. You could run this in a container or upgrade, I'll check the suggested link at since that's where Forem recommends you start. Sadly, this ends up using the obvious apt installable version so it's off to https://redis.io to download it. is the latest stable version is the first thing I see, 6.2 > 6.0 and we're off to the races.
6.2.1 is running on port 6379 on localhost and all is well with redis.
Elasticsearch is something that's a little controversial. Perhaps in response to AWS targetting their business, they recently made some modifications to their licensing terms for self-hosted applications permissible uses, causing community uproar and even more AWS targetting their business. We can focus on the minimum requirements here (running just es in docker would not be a bad choice, as I already have a docker instance downloaded from the first pass).
This is a long running service, running it in a shell like this might be a bother if you're not in the habit of letting shell sessions accumulate. tmux or screen or some other process manager might make sense, but I'll leave it in a shell session (in emacs I can just name this *elasticsearch process* and leave it alone. For the time being I'll leave the default settings in place (if java uses too much memory or ES starts to fail because of resource constraints it would be time to adjust that, but I'll hope for the best for now):
Assuming all went well, we can hit the port 9200 with curl and get the expected healthcheck response
I think I fall into the "older system node" category here and I also want to install nvm
Just to double check the node command uses the right nvm provided binary now
I'll ignore the npm upgrade warning (it's really regrettable that this happens immediately after installing node, and not important for what we're doing here).
Fortunately this was already set up (you might have rbenv but not the right version if you worked with another project, rbenv install 2.7.2 would fix that)
It looks like the setup script did not choke creating a db so my postgresql setup is "permissive" or functional (which saves a trip to pg_hba.conf or a call to createuser)
Checking the local postgres instance I can see both the dev and test instances were populated:
Login as admin@forem.local using the password password (from the seed data) and now I get redirected to "onboarding" - success. I guess that means the problems I had were docker specific (and possibly docker-compose is not fully working or has gotten out of sync with what the native environment is doing).
fill in some of the required fields, and the update setting text - you must fill in all of the above (I suggested admin_mcadmin be followed during onboarding).
My username is @admin_mcadmin and this action is 100% safe and appropriate.
Once you've passed this point - the "you forgot to setup" banner goes away and you have a local test instance.
Assuming all went well, we'll connect using redis-cli and ask what the server version is
I'll follow the guide at but grab the oss version since that's what points out.
Grabbing nvm from suggests download from the internet and pipe to bash. This isn't the most secure idea, but assuming we trust github not to attack us (I do), and the nvm-sh user not to have been compromised (I probably shouldn't, there have been a lot of these hijackings and they're pernicious) we can follow their instructions:
Yarn is ready to install after nvm builds node 14 for us. The install instructions at look a little scary (there's a note that this is all old and deprecated and the new yarn 2.0 install instructions are elsewhere). As a sanity check I looked at the . file in my forem directory with the yarn-path, it points to .yarn/releases/yarn-1.22.5.js for me, so I'm pretty sure either my system, or the docker system, was using yarn 1 and not 2 and I'll continue doing that. Since I see that's checked into forem's repo, I'm pretty sure I didn't put it there and that's an expected version for the system (which removes a lot of doubt I might have had here).
suggests copy env (done) and run bin/setup. At this point I got stung with the build extensions for the wrong linux and nuked the content of vendor and re-ran bundle.
navigate to (looks good - different lorem ipsum text articles but still looks like a Forem)
It looks like the banner that used to say "site not configured" now just lets me know I should have used bin/startup instead of rails server to start the site (since sidekiq background job processing is pretty integral to the system). Let's take a look atto see what we need - looks like webpack and sidekiq. I could stop the service and restart with start (I recommend you do this) or just start the other two processes in a shell. Starting sidekiq gives me back the "Setup is not completed yet" prompt to visit the configuration page (which is my next step after I start webpack)
is where I'm directed to go, now that I'm a site admin I think this will work.
