Preview our new batteries-included tools for self-hosting Ghost using Docker Compose.
/opt/ghost
:
.env
file and change:
DOMAIN
: this is your custom domain for your Ghost site e.g. mysite.comADMIN_DOMAIN
: a separate domain for your Ghost admin e.g. admin.mysite.com (Optional, recommended)DATABASE_ROOT_PASSWORD
: generate a random password with openssl rand -hex 32
DATABASE_PASSWORD
: generate a random password using openssl rand -hex 32
DOMAIN
, you’ll need to do option 3 in the next section to ensure ActivityPub works correctly.
Caddyfile
in caddy/Caddyfile
:
DOMAIN
in .env
:
Redirect the www variant to your root domain by setting up DNS for both domains and then uncomment the “Redirect www -> root domain” block.DOMAIN
in .env
:
Redirect your root domain to the www variant by setting up DNS for both domains, then uncomment the “Redirect root -> www domain” block” and set CHANGE_ME
to your root domain without the www. This is required for ActivityPub to work correctly with www domains.CHANGE_ME
. All the other variables come from .env
and should be left as-is.
/ghost
to complete your setup 🎉
/opt/ghost
, run the following 4 commands:
analytics
to the COMPOSE_PROFILES
variable at the top. This automatically includes the analytics
profile when running docker compose
commands:
activitypub
to the COMPOSE_PROFILES
variable at the top. This automatically includes the activitypub
profile when running docker compose
commands:
ACTIVITYPUB_TARGET
line to point to your local install. It should look like this:
docker compose
to install new images and run Ghost with ActivityPub:
docker compose
to update Ghost regularly:
.env
you’ll need to recreate the Ghost container.
DOMAIN
, ADMIN_DOMAIN
or ACTIVITYPUB_TARGET
are changed in the .env
file, the Caddy container also needs recreating:
.env
that are used in the compose.yml
the service using the variable will also need recreating in the same way.
The single exception is the DATABASE_xxx
variables. These must not be changed
once the database has been initialised, as it will change the config, but not the
actual values the database expects, thefore causing connection errors.
CTRL+C
and then running bash recovery_instructions.sh
to restore your original Ghost site. The migration script can be run multiple times if it errors without issue.
The migration script doesn’t delete any data. After you’ve migrated you should remove your existing installation once you’re happy.
docker compose logs caddy
to see the webserver logs. Try this first if you get an error like “This site can’t be reached”.
Use docker compose logs ghost
to see the Ghost logs as the next step.
If your issue is clearly with a different service, docker compose logs [service]
will show you more details.
If you get really stuck, post the details on https://forum.ghost.org.
TINYBIRD_API_URL
: This is the API url for your Tinybird workspace, which Ghost uses to make requests to your Tinybird workspace’s endpoints. The value will vary depending on which cloud / region your workspace is hosted in. You can find this value by running tb info
from the Tinybird CLI and using the value of the api
key, or in the Tinybird UI by going to Endpoints, selecting any endpoint, and finding the full URL of the endpoint.TINYBIRD_ADMIN_TOKEN
: This is a token that is automatically created by Tinybird, which enables any operation in your workspace. You can find it in your Tinybird workspace’s UI under the “Tokens” tab, named “Workspace admin token”. Ghost uses the admin token to sign JWTs, which Ghost and Admin use to authenticate with Tinybird’s API endpoints.TINYBIRD_WORKSPACE_ID
: This is a unique identifier for your workspace generated by Tinybird. You can find it in your Tinybird workspace’s UI under Settings. Ghost also uses this value to sign JWTs to authenticate with Tinybird’s API endpoints.TINYBIRD_TRACKER_TOKEN
: This is a token that grants write access to the main analytics_events
datasource in Tinybird. You can find this value in the Tinybird UI under “Tokens”. This is passed to the traffic-analytics
service, which adds it to each request that is proxied to Tinybird.ghost-docker
repo includes handling for these “migrations” to run automatically when running docker compose up
. Provided you’ve followed the initial setup instructions for traffic analytics, there shouldn’t be any intervention required to update your Tinybird workspace when updating to a new version of Ghost.
docker compose pull
and docker compose up -d
as part of the normal upgrade process, this will pull the latest version of the Ghost container to your host. This container includes the Tinybird datafiles.tinybird-login
container will run. Assuming you’ve already logged in to Tinybird as part of your initial setup, this service will noop. If you’re not logged in to Tinybird already for any reason, this service will fail, which means the Tinybird migrations did not run.
docker compose run --rm tinybird-login
first, then run docker compose up -d
again.tinybird-login
has completed successfully, the tinybird-sync
service will run in the new Ghost container. This service copies the Tinybird files from the Ghost container into the tinybird_files
volume, then exits.tinybird-sync
service completes successfully, the tinybird-deploy
service will run. This service will create and promote a new deployment in your workspace with the changes (if any) to the files in the tinybird_files
volume to Tinybird, using the tb --cloud deploy
command of the Tinybird CLI.tb --cloud deploy
command technically doesn’t run “migrations” in the traditional sense at all. Instead it compares your local Tinybird datafiles with what is currently deployed to your workspace to figure out what needs to change (if anything). If your workspace isn’t up-to-date with your local Tinybird datafiles, the CLI will create a new deployment with the changes. Once the new deployment is complete and healthy, Tinybird will promote it to be the current “Live” deployment, and remove the previous deployment.
You can view all the deployments in your workspace in the Tinybird UI under “Deployments” in the left sidebar, or use the tb deployment
commands to interact with deployments via the CLI. For more information on what deployments are and how they work, read Tinybird’s docs on deployments.
tinybird-*
services fail, don’t panic! The previous deployment in your Tinybird workspace should still be live and healthy. If a deployment fails for any reason, you’ll need to diagnose what went wrong, fix it, then run docker compose up -d
to try again.
Here are a few steps you can take to start troubleshooting:
tinybird-login
service using docker compose logs tinybird-login
. If this service was successful, you should see “Tinybird already logged in” in the logs. If this service failed for any reason, try authenticating with Tinybird again using docker compose run --rm tinybird-login
.tinybird-sync
service using docker compose logs tinybird-sync
. If this service was successful, you should see “Tinybird files synced into shared volume.”tinybird-deploy
service using docker compose logs tinybird-deploy
. This will show the complete logs from the latest attempt to deploy changes to your Tinybird workspace, which should hopefully tip you off to what went wrong.