The local dev environment runs a PostgreSQL 16 instance and a development container with the full C++ toolchain (compiler, linker), plus PostgreSQL and Redis servers. Your local source tree is mounted into the container, so edits on your machine are built inside the container. There are two ways to bring it up: Docker Compose (recommended) or a manualDocumentation Index
Fetch the complete documentation index at: https://docs.springtail.io/llms.txt
Use this file to discover all available pages before exploring further.
docker run.
Prerequisites
- Docker and Docker Compose
- Python 3
Installing a container runtime (macOS)
Install Homebrew, then a container runtime:Colima (preferred)
Install colima and docker (this is preferred); make sure you are usingmacOS Virtualization.Framework and virtiofs with colima.
NOTE: Rosetta is a x86 translation layer, if not using Apple Silicon Mx then it may not be necessary.
Docker Desktop
If using Docker Desktop you may need to set some options to enable Rosetta and VirtioFS. See: https://www.docker.com/blog/docker-desktop-4-25/ Go to Settings→General and select VirtioFS and Rosetta.Quick Start (Docker Compose)
1. Build the base Docker image
From the repository root:springtail:base image from Dockerfile.base, which includes a patched PostgreSQL 16 (built from source with RLS support for foreign tables), Redis, the C++ toolchain, and all Ansible-provisioned dependencies.
2. Start the dev environment
| Service | Container | Description | Host Port |
|---|---|---|---|
postgres | pg16 | PostgreSQL 16 with logical replication enabled | 5432 |
dev | dev-springtail | Development container with build tools | 2222 (SSH) |
/home/dev/springtail and starts PostgreSQL, Redis, and SSH automatically via its entrypoint.
3. Build Springtail inside the container
Shell into the dev container and run the debug build:4. Run the unit tests (C++ / CTest)
check target kills any running Springtail processes, installs SQL triggers, builds the tests, and runs them via CTest.
5. Run the integration tests
The integration test runner is a Python script that exercises Springtail end-to-end against a real PostgreSQL instance. It must be run from its own directory:basic, framework, preload, enum_bits, complex, numeric, query_benchmark, and recovery (with various overlay configurations).
Common test_runner.py options
basic, complex, enum_bits, framework, include_schema, large_data, live_startup, numeric, policy_roles, preload, query_benchmark, recovery, text_tables.
Available overlays: small_log_rotate, small_log_rotate_with_streaming, small_cache_size, streaming_postgres_config, integration_test_config, include_schema_config.
6. Tear down
Alternative: manual container (docker run)
Instead of Docker Compose, you can build and run the dev container by hand.
Build the image
- The
-poptions will map the ports from container to host. Use Postgres (5432), Redis (6379) and SSH (22) (only SSH is required). - The
-voption will map your local springtail github source into the container (source:target). The source should be your local springtail dir, the target must be/home/dev/springtail. The source is the location at which you checked out and cloned the github source code; replace<springtail_dir>. - The
--privilegedand--cap-add=SYS_PTRACEoptions may be useful for debugging to attach to a running process
entrypoint.sh as the container entry point. This script ensures the Postgres and Redis services are running, and it creates the Postgres springtail user. The Dockerfile also edits the Postgres configuration as necessary.
Logging in
You should see 3 directories after logging in:springtail directory should be the mounted directory from your local machine containing the code. The debug directory is where the code will be built within the container, and the external directory will host the vcpkg packages and source.
Building
From within the dev container; this will create symlinks to../debug and ../external and will start the build. First it will download vcpkg and build it, then it will download the dependency packages and build them, lastly it will build the Springtail code.
Troubleshooting the build
- Check for the existence of the following two files, and make sure they are symlinks:
debug -> /home/dev/debug/external -> /home/dev/external/
- Sometimes running
./debug.shresults in errors while building the external dependencies in vcpkg. If this happens, just try rerunning./debug.shand see if you can make progress (i.e., check if it is failing on a different dependency, if so keep going).
Operating the environment
After Mac reboot
After reboot if your container is no longer accessible, check if colima is running and if not start it:docker run command instead of docker container start, it will fail as follows:
Running out of space
If you have trouble with disk space or RAM or CPU, you can restartcolima:
VS Code
Since you have mounted thespringtail source dir into the container, the code it is building is the same code on your local machine. Any edits to the code on your local machine will be reflected in the container. So after you make a code change, just rebuild from the container (cd debug; make).
Dev containers
If you are using VSCode or Cursor (based on VSCode), and want more functionality to just work, it is best to have VSCode connect to the docker image and edit there. You can do this by installing the “Dev Containers” extension. And then access the Command Palette (cmd+shift+P) and run “Dev Containers: Attach to Running Container…”. You can then select your container. It will first connect as “root”, which is not what you want, so then run “Dev Containers: Open Container Configuration File” and set the contents to the following:Clangd
Additionally, in VSCode, I’d recommend installing theclangd extension, and also run sudo apt install clangd inside of your container. After installing the VSCode extension, you should get an option to disable “Microsoft Intellisense” (as both extensions provide the same functionality). The clangd extension should give much more accurate/faster support for “Find all references”.