This is a repo for setting up a free, self-managed install of Forem on a Fedora CoreOS VM running on one of a few popular cloud providers (current support for DigitalOcean, AWS, and Google Cloud). Local development is also supported using a VM on Linux via QEMU.
Please note that Forem is a complex piece of software, and hosting and managing it in a cloud environment is non-trivial. While the recipes and scripts here are expected to work for the limited scenarios we tested against, use and modification of the recipes, or altering the deployed environment, may require familiarity with the following layers of the tech stack we built with, and ongoing maintenance of the deployed system may require interacting with any of these technologies:
If a Self-Hosted Forem is not right for you, we offer a fully-managed, enterprise solution called Forem Cloud; no technical setup required. For more information, please contact us via this form.
For those that want to DIY beyond the scope of this repo, you can use the systemd units in the Butane template as an example of how to run Forem without Fedora CoreOS on a Linux distribution that supports systemd, or customize that template to fit your needs or create a bootable Ignition configuration to consume on bare metal or in a custom VM.
The goal of this project is to provide you with the choice, freedom, and cost-effectiveness to host your own Forem community as you see fit.
We can't wait to see the community you selfhost with Forem!
brew install python3
Note: This will likely use Python 3 at
/usr/local/bin/python3, not/usr/bin/python3, requiring that you setansible_python_interpreterto/usr/local/bin/pythonin inventory or via extra vars (eg-e ansible_python_interpreter=/usr/local/bin/python)
ansible-core 2.11 or greater (provided by Ansible 4.0.0)brew install butanepwgen
brew install pwgenNote: Some provisioning targets have additional requirements that are detailed out in each respective section.
Note: Following this quick start guide with the cloud provider of your choice will cost you money! Please consult with each cloud provider to figure out how much your Forem will cost you per month.
Start by cloning the forem/selfhost repository to your local computer and change into the newly created directory:
git clone https://github.com/forem/selfhost.git
cd selfhostAfter this step you have two choices: a semi-automated setup via a script or a completely manual installation.
We have a script in place that will perform several of the necessary setup tasks for you. It will take care of the first 3 steps of the manual installation process (installing Python dependencies, generating an Ansible Vault password and copying the inventory definition for you). It will also generate the secrets needed for step 4.
./setup
Verifying that pip is available
Installing Python dependencies
[output omitted]
Generating Ansible Vault secret
ixooGe3ob0shob8soo6AhYie
Copying example inventory
'inventory/example/setup.yml' -> 'inventory/forem/setup.yml'
Generating Vault secrets
[output omitted]
Use these secrets to replace the placeholders in inventory/forem/setup.ymlOnce the script finished running, continue from step 4. of the manual installation process described below.
1) Install Python dependencies:
pip3 install -r requirements.txtvenv module:
python3 -m venv /path/to/new/virtual/environmentsource <venv>/bin/activatepip3 install -r requirements.txtdeactivate (leaves the virtual env)
1) Generate an Ansible Vault passwordmkdir -p ~/.config/forempwgen -1 24|tee ~/.config/forem/selfhost_ansible_vault_password
1) Copy example Ansible Inventory from inventory/example/setup.yml to inventory/forem/setup.yml
1) Edit inventory/forem/setup.yml Ansible Inventory with your Forem settingsansible-vault encrypt_string to create the secrets listed below. See "Required Ansible Vault secret variables" in the example setup.yml, which contains the required commands to generate each variable's value:
${HOME}/.ssh/forem. Use ls -lh ~/.ssh/forem* to ensure you have both a ${HOME}/.ssh/forem private key, and a corresponding ${HOME}/.ssh/forem.pub public key.
~/.ssh/id_rsa.pub.
Please visit the AWS RSA based SSH key section in our Self Host: Quick Start in Depth guide for instructions on creating an RSA-based key.
1) Pick a supported cloud provider and set it up on your workstationsudo systemctl restart forem-traefik.service) via SSH on your Forem server to generate a TLS cert.
1) Go to your Forem domain name and create your first account. Please see the Forem Admin documentation located here for more information on setting up your Forem.Note about recommended instance types and cost: for each hosted provisioning target below, we attempted to recommend an instance type with 2 CPUs, 2GB of RAM, and a monthly cost of around $15 USD. Please note that providers may charge additionally for disk space, network usage, etc, so your price per month may vary based on your Forem's usage and needs. For exact and specific pricing information, please see each provider directly.
The AWS provisioning target has a few preset variables that can be either edited in the playbook or passed along as Ansible extra vars on the CLI.
fcos_aws_region: us-east-1
fcos_aws_size: t3a.small
fcos_aws_ebs_size: 100
ssh_key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"fcos_aws_region: the AWS region that is used to setup your Forem server. The default region is in us-east-1 which is in North Virginia, USAfcos_aws_size: the AWS EC2 instance type. A recommended type is a t3a.small EC2 instance, with 2 VCPUs and 2GB of RAMfcos_aws_ebs_size: the amount of EBS disk space (in GB)ssh_key: the path to a public SSH key. Note that AWS's EC2 service can only use RSA based SSH keys. If you get an error that your SSH key is not the right type, please generate an RSA based SSH key and set ssh_key with a lookup path to that key1) Install the Ansible Amazon AWS collections ansible-galaxy collection install amazon.aws community.aws or install them via ansible-galaxy collection install -r requirements.yml
2) Download and install the AWS CLI version 2 tool
3) Install boto, boto3, and botocore pip3 modules pip3 install boto boto3 botocore or run pip3 install -r requirements.txt
4) Create an AWS IAM user with Programmatic access called forem-selfhost with the following AmazonEC2FullAccess, AmazonS3FullAccess, AmazonVPCFullAccess AWS managed policies attached. Be sure to save the Access key ID and Secret access key to use in step 5.
5) Run aws configure --profile forem-selfhost and input the access key ID and secret key when prompted. We use us-east-1 for default region name but you can choose a different one if you wish. Set default output format to json
1) Run the AWS provider playbook to setup your Forem
ansible-playbook -i inventory/forem/setup.yml playbooks/providers/aws.ymlThe DigitalOcean provisioning target has a few preset variables that can be either edited in the playbook or pass along as Ansible extra vars on the CLI.
forem_do_region: nyc3
forem_do_size: s-2vcpu-2gbforem_do_region: the DigitalOcean region that is used to setup your Forem server. The default region is nyc3 which is in New York City, New York, USAforem_do_size: the Droplet size. The recommended size is s-2vcpu-2gb, with 2 Shared CPUs, 2GB of RAM, a 60GB SSD disk, and 3TB of outbound transfer.1) Install the DigitalOcean Ansible collection ansible-galaxy collection install community.digitalocean or install it via ansible-galaxy collection install -r requirements.yml
2) Download and install doctl
3) Create DigitalOcean Auth Token
4) Run doctl auth init and pass the API token created from step 3 and verify that you can authenticate to the DigitalOcean API with doctl account get. If you used a context here, you'll need to also doctl auth switch.
1) Run the DigitalOcean provider playbook to set up your Forem
ansible-playbook -i inventory/forem/setup.yml playbooks/providers/digitalocean.ymlNote: DigitalOcean does not have support for Fedora CoreOS. We have to upload a custom image to your account via Ansible. If the "Wait for fcos-{{ fcos_download_release }} to be created" task times out. please check the Custom Images section on your DigitalOcean account to see if your image is still in a pending state. Wait for it to finish processing and re-run the DigitalOcean provider playbook.
The Google Cloud provisioning target has a few preset variables that can be either edited in the playbook or pass along as Ansible extra vars on the CLI.
forem_gcp_region: us-central1
forem_gcp_zone: a
forem_gcp_machine_type: e2-small
forem_gcp_disk_size: 100
forem_gcp_project_id: forem-selfhost-12345forem_gcp_region + forem_gcp_zone: the Google Cloud region and zone that is used to setup your Forem server. The default region is us-central1 in zone a which is in Council Bluffs, Iowa, USAforem_gcp_machine_type: the GCP machine type. A recommended type is e2-small, with 2 shared CPUs and 2GB of RAMforem_gcp_disk_size: the amount of disk space (in GB)forem_gcp_project_id: your GCP project ID1) Install the Google Cloud collection ansible-galaxy collection install google.cloud or install it via ansible-galaxy collection install -r requirements.yml
2) Install requests and google-auth pip3 modules pip3 install requests google-auth or run pip3 install -r requirements.txt
3) Create a Google Cloud Service Account called forem-selfhost with Compute Instance Admin (v1) privileges and download a JSON credentials file and place it in ~/.gcp/forem.json
1) Run the Google Cloud provider playbook to setup your Forem
ansible-playbook -i inventory/forem/setup.yml playbooks/providers/gcp.ymlWe provide some example Dynamic Inventories for you to use on your self-hosted Forem. You can use them to run Ansible Adhoc Commands or write your own Ansible playbooks to manage your Forem.
See the SSH Examples for some commands that you can run with an Ansible Adhoc command.
Show all Forems on AWS
ansible-inventory -i inventory/providers/aws/ --graph forem
Run an Ansible Adhoc command on all Forems on AWS
ansible -i inventory/providers/aws/ -m command -a "hostname" forem
_Note: You need to run export DO_API_TOKEN=your_digitalocean_api_token before running the ansible-inventory or ansible commands!_
Show all Forems on DigitalOcean
ansible-inventory -i inventory/providers/digitalocean/ --graph forem
Run an Ansible Adhoc command on all Forems on DigitalOcean
ansible -i inventory/providers/digitalocean/ -m command -a "hostname" forem
Note: You need to edit the project list in inventory/providers/gcp/gcp.yml with your GCP project for this Ansible Inventory Dynamic to work correctly!
Show all Forems on Google Compute
ansible-inventory -i inventory/providers/gcp/ --graph forem
Run an Ansible Adhoc command on all Forems on Google Compute
ansible -i inventory/providers/gcp/ -m command -a "hostname" forem
This section covers how Forem is configured and run on Fedora CoreOS.
Forem is run with a stack of containers that are powered via Podman and systemd. The systemd unit files are located in /etc/systemd/system:
$ cd /etc/systemd/system
$ ls -lah forem*
-rw-r--r--. 1 root root 243 Jun 29 17:16 forem-container.service
-rw-r--r--. 1 root root 833 Jun 29 17:16 forem-imgproxy.service
-rw-r--r--. 1 root root 1.1K Jun 29 17:16 forem-openresty.service
-rw-r--r--. 1 root root 787 Jun 29 17:16 forem-pod.service
-rw-r--r--. 1 root root 904 Jun 29 17:16 forem-postgresql.service
-rw-r--r--. 1 root root 1.4K Jun 29 17:16 forem-rails.service
-rw-r--r--. 1 root root 941 Jun 29 17:16 forem-redis.service
-rw-r--r--. 1 root root 951 Jun 29 17:16 forem-traefik.service
-rw-r--r--. 1 root root 1006 Jun 29 17:16 forem-worker.service
-rw-r--r--. 1 root root 691 Jun 29 17:16 forem.serviceWe use systemd unit dependencies heavily to correctly configure the start of service required to power your Forem.
The first systemd unit that runs on boot is forem-container.service. This service interfaces with foremimg to pull down the Forem container image and ensure that the localhost/forem/forem:current container tag is present.
We then create a Podman pod with the forem-pod.service to run all of the Forem services within it. Pods are a group of one or more containers that share the same network, pid and ipc namespaces. This means that localhost is isolated inside the pod and shared across all of the containers within the pod. The pod also binds ports 80 and 443 on the Fedora CoreOS server.
We then launch all of the required services within this Podman pod: forem-imgproxy.service, forem-postgresql.service, forem-redis.service. All of these services use the systemd BindsTo directive which configures a strong dependency on forem-pod.service. This means if forem-pod.service is stopped or it enters an inactive state, all of these services will stop too. Also, all of these services have to be up before our next unit, forem.service can start successfully.
The forem.service unit uses the BindsTo directive to bind forem-rails.service, forem-worker.service, and forem-openresty together as they are tightly dependent on each other to run Forem. This means you can stop and start the forem.service unit via systemctl and it will stop the three main Forem units, too. This service also ensures that forem-pod.service, forem-postgresql.service, forem-imgproxy.service, and forem-redis.service units are active and that the local container localhost/forem/forem:current exists before starting.
The main Forem systemd units are forem-rails.service, forem-worker.service, and forem-openresty. The forem-rails.service creates container volume mount /opt/forem/data/uploads on the Fedora CoreOS host and mounts it inside the container at /opt/apps/forem/public/uploads. The Forem Containerfile uses a VOLUME directive to create a container volume /opt/apps/forem/public and it puts all of the Forem public assets (CSS and JS) inside. These volumes are shared between the other main Forem containers: forem-worker.service, and forem-openresty.
The forem-rails.service is the main Ruby on Rails application that is running Puma which is a very fast and concurrent HTTP 1.1 application server.
The forem-worker.service is the background worker container that runs Sidekiq.
The forem-openresty.service runs OpenResty which is a dynamic web platform based on NGINX and LuaJIT. We use OpenResty to proxy connections to Puma in the forem-rails.service unit. We also use OpenResty to send proxy requests to forem-imgproxy.service for image resizing, which are then cached in OpenResty.
The last service we use in the configuration phase is forem-traefik.service. It is responsible for handling traffic from the Internet and passing it into the Forem Pod to forem-openresty.service, which then manages the traffic to forem-rails.service. It also manages the TLS certificate from Let's Encrypt and handles the redirection from HTTP to HTTPS.
All of your Forem's data and configuration resides in /opt/forem. This is the most important directory on your Forem. You should backup this directory regularly.
# ll /opt/forem/
total 4
drwxr-x---. 3 root root 39 Jun 29 17:16 configs
drwxr-x---. 5 root root 52 Jun 29 17:16 data
drwxr-x---. 2 root root 82 Jun 29 17:16 envs
drwxr-xr-x. 2 root root 6 Jun 29 17:16 tmp
-rw-r--r--. 1 root root 37 Jun 29 17:16 version
The configs directory contains the OpenResty (Nginx) configuration file and the Traefik configuration TOML files, along with the acme.json, which holds the TLS certificate from Let's Encrypt.
# ll
total 4
-rw-r--r--. 1 root root 2375 Jun 29 17:16 nginx.conf
drwxr-x---. 2 root root 63 Jun 29 17:16 traefik
# ll traefik/
total 12
-rw-------. 1 root root 3524 Jun 29 17:20 acme.json
-rw-r--r--. 1 root root 1928 Jun 29 17:16 dynamic.toml
-rw-r--r--. 1 root root 740 Jun 29 17:16 traefik.tomlThe data directory contains your postgresql, redis, and upload directories. This directory contains all of your Forem content including your members.
# ll data/
total 4
drwx------. 19 polkitd root 4096 Jun 29 17:19 postgresql
drwxr-x---. 2 polkitd root 28 Jun 29 17:19 redis
drwxr-x---. 2 core core 6 Jun 29 17:16 uploads
The envs directory contains all of the environment variable files that configure the following Forem services:
forem-imgproxy.service with imgproxy.envforem-postgresql.service with postgresql.envforem-rails.service, forem-worker.service with rails.envforem-redis.service with redis.env# ll envs/
total 12
-rw-r-----. 1 root root 319 Jun 29 17:16 imgproxy.env
-rw-r-----. 1 root root 85 Jun 29 17:16 postgresql.env
-rw-r-----. 1 root root 1483 Jun 29 17:16 rails.env
-rw-r-----. 1 root root 0 Jun 29 17:16 redis.env
If you have to make a configuration to a service, you can edit the respective ENV file and restart the service via systemd. For example, systemctl restart forem.service after editing the rails.env file.
The version file is written out by the forem-container.service systemd unit and foremimg script.
Note: Making changes to these files can prevent your Forem from starting and cause downtime. Make changes with care and create backups!
All of these examples need to be run via SSH on the Fedora CoreOS server as the core or root user. You can access your Forem server via SSH:
ssh core@<SERVER IP ADDRESS>If your key doesn't have a default name like id_dsa, id_ecdsa, id_rsa, etc. you must specify it with the -i identity_file option. For example, this is the command you need to run for a key named forem:
ssh -i ~/.ssh/forem core@<SERVER IP ADDRESS>We have a helper script (Forem Control) called foremctl. It is used to control your Forem via CLI.
$ foremctl help
Usage: foremctl {console|deploy|help|rake|restart|start|stat|status|stop|update|version}
console Open a Rails console
deploy Updates and deploy the most current version of Forem
help Show this message
rake Run a rake task
restart Restart Forem
start Start Forem
stats Show CPU, RAM, Disk IO usage of the Forem containers
status Show the current running Forem containers
stop Stop Forem
update Updates Forem to the lastest container
version Shows information on the current running version of Foremsudo foremctl deployNote: The deploy process causes a small amount of downtime while the Forem code restarts.
We have a helper script (Forem Image) called foremimg. It is used to control your Forem's version and apply updates. It has to be run as the root user.
# foremimg help
Usage: foremimg {help|rollback|show}
help Show this message
rollback Issue a rollback
show Show tags: current|rollback
current Show what image is tagged with current
rollback Show what image is tagged with rollback
Running foremimg with no flags will read /opt/forem/version if present for the
container tag or write /opt/forem/version with the default tag quay.io/forem/forem:latest
Running foremimg quay.io/forem/forem:testing will write quay.io/forem/forem:testing
to /opt/forem/version and pull this container and point the local container
image tag 'localhost/forem/forem:current' to 'quay.io/forem/forem:testing'
and point the previous image to 'localhost/forem/forem:rollback'
Rollbacks:
Running 'foremimg rollback' will swap 'localhost/forem/forem:rollback' with 'localhost/forem/forem:current'
sudo foremimg quay.io/forem/forem:testing
sudo foremimg update
sudo foremimg rollback
sudo foremctl restart
Check for updates:
$ sudo rpm-ostree upgrade --check
2 metadata, 0 content objects fetched; 16 KiB transferred in 1 seconds; 0 bytes content written
AvailableUpdate:
Version: 34.20210529.1.0 (2021-06-01T19:22:39Z)
Commit: 936a0a142a09ebf8fa25d50a93377d8822c4ab3bfcf477a73781823569dbd33f
GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39
Diff: 380 upgraded, 22 removed, 17 addedPreview the package updates:
$ sudo rpm-ostree upgrade --previewDownload the packages without deploying them:
$ sudo rpm-ostree upgrade --download-onlyTo apply the updates and reboot:
$ sudo rpm-ostree upgrade
$ systemctl rebootNote: Fedora CoreOS is an immutable Linux distribution. You will have to reboot to have the updates take effect. This will cause downtime for your Forem.
If the update causes issues with your Forem, you can issue a rollback with:
sudo rpm-ostree rollback --rebootYou can make a backup of your Forem data by creating gzipped tarball of /opt/forem. You will want to download this file to your local computer via SCP.
foremctl stop
sudo tar czpf ~core/"$(date '+%Y-%m-%d')-forem-data.tar.gz" /opt/forem
foremctl startNote: Running foremctl stop will cause downtime for your Forem!
To support local development, you will need a Linux workstation with virtualization enabled in the BIOS and KVM installed. You can check your workstation to see if it has support for Intel VT/AMD-V Virtualization with this command:
grep --color "svm\|vmx" /proc/cpuinfoIf that doesn't return anything, you might need to enable virtualization support in your BIOS.
In order to set up your development VM, you'll need a Linux workstation or server with the following packages:
pip3 install -r requirements.txt)virt-installFedora
$ sudo dnf install -y @virtualization butane podmanRHEL/CentOS
$ sudo yum install -y qemu-kvm virt-install virt-manager podmanUbuntu
$ sudo apt install virt-managerDebian
$ sudo apt install qemu-kvm libvirt-binBefore creating your development VM, you must supply an SSH key. SSH is the
primary method you'll use to interact with the development VM. Ansible will look
for a public key at the following path /${HOME}/.ssh/forem.pub.
Creating a symbolic link to your SSH key is a good way to handle this:
ln -s <path_to_your_private_ssh_key> ${HOME}/.ssh/forem.pubAdd this to your ~/.ssh/config file:
Host devel.forem.wtf
ForwardAgent yes
StrictHostKeyChecking no
UserKnownHostsFile=/dev/nullIn order to encrypt your variables, you need an Ansible Vault password. This password needs to be set once and never changed. If you lose this password or change this password you will need to reset all of your encrypted variables.
mkdir -p ~/.config/forem/
pwgen -1 35 | tee ~/.config/forem/selfhost_ansible_vault_password1) Copy example Ansible Inventory from inventory/example/setup.yml to inventory/forem/setup.yml
2) Edit inventory/forem/setup.yml Ansible Inventory with your Forem settings
ansible-playbook -i inventory/forem/setup.yml playbooks/providers/qemu.ymlssh core@devel.forem.wtf -p 2222