DevContainer Configuration for Codespaces
VS Code Dev Container config for one-click cloud and local dev — GitHub Codespaces, JetBrains Gateway, and VS Code, with the Jekyll toolchain pre-installed.
DevContainer Configuration
zer0-mistakes ships a .devcontainer/devcontainer.json that lets you open a fully configured Jekyll development environment with a single click — no local Ruby, Bundler, or Node installation required.
Supported Environments
| Environment | How to open |
|---|---|
| GitHub Codespaces | Click Code → Codespaces → Create codespace on main |
| VS Code Dev Containers | Open the repo folder → Reopen in Container |
| JetBrains Gateway | Connect to Codespace or remote Docker host |
Configuration File
.devcontainer/devcontainer.json
What’s Pre-Installed
Instead of pulling a generic base image and installing gems on every launch, the devcontainer builds from the repo’s own docker/Dockerfile (the dev-test stage). That stage runs bundle install at image-build time, so the whole Jekyll toolchain is preloaded into the image — the gems always match the checked-out branch’s Gemfile.lock, and there’s no slow bundle install on first boot.
| Tool | Source |
|---|---|
| Ruby 3.3 + Bundler + Jekyll toolchain | docker/Dockerfile dev-test stage (gems baked in) |
GitHub CLI (gh) |
devcontainers/features/github-cli:1 |
Docker-in-Docker and a standalone Node install are intentionally not included — they aren’t needed to render the site (Playwright/Sass run on the host), and dropping them keeps Codespace creation and prebuilds fast.
Near-instant launch with prebuilds
Because the image is self-contained, GitHub Codespaces prebuilds can build it ahead of time so new Codespaces restore from a ready image in seconds. Enable it under Settings → Codespaces → Set up prebuild (target main, trigger On configuration change). See .devcontainer/README.md.
Post-Create Hook
git config --global --add safe.directory ${containerWorkspaceFolder} && (bundle check || bundle install --jobs 4 --retry 3)
bundle check is a fast no-op when the gems are already baked into the image; it only falls back to a full install if the lockfile drifted.
Post-Start Hook
bundle exec jekyll serve \
--config '_config.yml,_config_dev.yml' \
--host 0.0.0.0 --port 4000 --livereload --force_polling
The Jekyll dev server starts automatically every time the container starts (nohup keeps it alive after the hook returns; --force_polling makes file watching reliable over the Codespaces bind mount; logs land in /tmp/jekyll-serve.log). The site is available at http://localhost:4000 and forwarded automatically in VS Code and Codespaces.
Forwarded Ports
| Port | Service |
|---|---|
4000 |
Jekyll site (auto-opens in browser) |
35729 |
LiveReload (silent) |
VS Code Extensions
The configuration recommends these extensions:
sissel.shopify-liquid— Liquid template syntax highlightingyzhang.markdown-all-in-one— Markdown editingDavidAnson.vscode-markdownlint— Markdown lintingstreetsidesoftware.code-spell-checker— Spell checkesbenp.prettier-vscode— Code formattingms-azuretools.vscode-docker— Docker management
Using the DevContainer Locally
If you have Docker Desktop installed, you can use the devcontainer without Codespaces:
- Install the VS Code Dev Containers extension
- Open the repo folder in VS Code
- Click the notification to Reopen in Container (or use the Command Palette → Dev Containers: Reopen in Container)
- Wait for the container to build (~2–3 minutes on first run)
- The site starts automatically at port 4000
Relationship to Docker Compose
The devcontainer and docker-compose.yml serve different purposes:
devcontainer.json |
docker-compose.yml |
|---|---|
| VS Code / Codespaces IDE integration | Team-wide dev server + multi-service stack |
| Extension recommendations, settings sync | Production-parity environment |
| Auto-start Jekyll on container start | Explicit docker-compose up required |
You can use either (or both) depending on your workflow.
Related
See also
- [[Development]]
- [[Docker]]
- [[Getting Started]]