Use the discourse_test image for testing
maindiscourse_test image is built on top of the standard Discourse image and includes additional testing tools and a default testing entrypoint.repository·main·Indexed 23 days ago
https://github.com/discourse/discourse_dockerDocker images and management tooling for deploying and managing Discourse forums. Includes the Launcher CLI for container lifecycle management, templates for standalone and distributed architectures, and a Setup Wizard CLI for installation configuration. Provides specialized image variants for runtime, building, development (discourse_dev), and testing (discourse_test), with build support via docker buildx bake.
discourse_test image is built on top of the standard Discourse image and includes additional testing tools and a default testing entrypoint.The Discourse Docker images are categorized into different functional roles. The base image contains all core dependencies (runit, postgres, nginx, ruby, imagemagick, etc.) and the discourse user. It has several tag variants:
runtime-deps: Runtime dependencies only.build-deps: Includes runtime-deps plus build tools for compiling gems, node, and pnpm.slim: Includes build-deps plus a Discourse clone (main and stable/esr varieties).web-only: Includes slim plus gems and node modules.release: Includes web-only plus redis and postgres.To build new images, use the docker buildx bake command. This process builds local images with predefined tags as defined in the docker-bake.hcl file in this repository.
To see a list of all valid build targets, run:
docker buildx bake --list targets
docker buildx bake {target}The discourse_dev image is an all-in-one container for development that includes redis and postgres.
Usage Requirements:
/src inside the container.discourse user is granted passwordless sudo permissions to facilitate command-line Docker tools that run as the discourse user.For utilities to assist with this setup, refer to the README in the main discourse/bin/docker directory of the discourse/discourse repository.
/templates directory contains templates managed by pups. These templates can be used to bootstrap your Discourse environment configuration.There are two primary ways to upgrade your Discourse instance:
http://yoursite.com/admin/upgrade to upgrade an already running image../launcher rebuild my_imageDiscourse container configurations (typically located at containers/app.yml) are structured using two primary top-level keys for settings:
env: Used for environment variables. Keys starting with DISCOURSE_, LETSENCRYPT_, or UNICORN_ are automatically categorized here.params: Used for other configuration parameters.Additionally, the templates key is an array used to include specific configuration templates, such as SSL or Let's Encrypt configurations.
SMTP_URL environment variable in your container configuration.Container definitions (typically YAML files in the /containers directory) use special sections to configure the Docker environment.
Use templates to compose your configuration from existing pups-managed templates found in /templates.
Use expose to publish ports. You can bind to specific host interfaces or just specify the container port to expose it without publishing.
Use volumes to map host directories to guest directories. This is recommended for persistent data like logs and uploads to ensure data survives container rebuilds.
Use links to connect the current container to another container (e.g., a database container).
Use env to set environment variables inside the container.
Use labels to add metadata to the container.
Hooks allow you to run code before or after template logic. You can find available hooks by searching templates for hook: or running grep -r "hook:" . in the repository.
### templates:
```yaml
templates:
- 'templates/cron.template.yml'
- 'templates/postgres.template.yml'expose:
- '2222:22'
- '127.0.0.1:20080:80'volumes:
- volume:
host: /var/discourse/shared
guest: /sharedlinks:
- link:
name: postgres
alias: postgresenv:
DISCOURSE_DB_HOST: some-host
DISCOURSE_DB_NAME: '{{config}}_discourse'labels:
monitor: 'true'
app_name: '{{config}}_discourse'hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_managerYou can customize the image building process by setting the following environment variables used by docker-bake.hcl:
| Variable | Description | Default |
|---|---|---|
ARCH | Image architecture | amd64,arm64 |
BASE_IMAGE | Base image repository | local_discourse/base |
TEST_IMAGE | Test image repository | local_discourse/discourse_test |
SETUP_WIZARD_IMAGE | Setup wizard image repository | local_discourse/setup-wizard |
DEV_IMAGE | Dev image repository | local_discourse/discourse_dev |
The Discourse Setup Wizard (running inside a container) cannot perform a full rebuild of the Discourse image itself because the rebuild process must run on the host machine. To bridge this, the wizard writes a signal file to a specific path inside the container: /discourse_docker/.wizard_rebuild_needed.
The host-side wrapper script monitors this file. When the file is detected, the wrapper script initiates the actual rebuild process on the host. If the rebuild(skip: true) option is used during the wizard process, this signal file is not created, and the rebuild is bypassed.
REBUILD_SIGNAL_FILE = "/discourse_docker/.wizard_rebuild_needed"