dockside

https://github.com/user-attachments/assets/2c5eb71b-9fcc-432a-9f4c-e3d0df4a380a

Introduction

Dockside is a self-hosted platform for teams who want a devcontainer for every branch — isolated, browser-accessible, HTTPS-secured, and ready in seconds, on your own infrastructure.

Each devcontainer (or devtainer, as we call them) is automatically provisioned with a browser IDE, SSH access, and a dedicated HTTPS reverse proxy with per-service subdomains. No per-project configuration required. Spin one up per branch, per task, per developer — or per AI agent session.

Note on terminology: Dockside’s devtainers are development containers in the general sense. They predate and differ from the VS Code devcontainer spec (.devcontainer/devcontainer.json), though they serve the same core purpose: a reproducible, isolated environment for each piece of work.

Running AI coding tools? Dockside devcontainers are natural sandboxes for Claude Code, OpenAI Codex, GitHub Copilot and similar. The Claude and Codex CLIs — and their VS Code extensions — run natively inside Dockside’s integrated IDEs. Each AI session is isolated in its own container. And coming soon: built-in network firewall management to define exactly what AI agents can reach, reproducing purpose-built AI devcontainer security without elevated capabilities or weakened isolation.

AI-assisted development

AI coding tools work best when they have their own isolated environment to operate in — somewhere they can install dependencies, run tests, edit files, and make mistakes, without affecting anything else. Dockside devcontainers are a natural fit.

• Claude Code and OpenAI Codex CLIs run natively inside Dockside’s integrated IDEs (OpenVSCode Server and Theia), as do their VS Code extensions. Point an AI agent at a fresh devcontainer, let it work, then review the result — all contained.
• Per-session isolation: each AI coding session gets its own devcontainer. Unintended side-effects — runaway processes, unexpected file changes, dependency conflicts — stay within that container’s blast radius and don’t touch your host or other devcontainers.
• Network firewall management (coming soon): configurable outbound firewall rules per Docker custom network, letting you define exactly what AI agents can and cannot reach. Assign a devcontainer to a restricted network and Dockside enforces the rules — without requiring elevated container capabilities or weakening isolation.

Why Dockside?

	Dockside	GitHub Codespaces	Gitpod	Coder
Self-hosted / private cloud	✅	❌	✅	✅
No per-seat cloud fees	✅	❌	❌	✅
Your data stays on your infra	✅	❌	❌	✅
Full root in containers	✅	❌	❌	Partial
AI CLI tools run natively in IDE	✅	Partial	Partial	Partial
Per-network outbound firewall for AI	✅ soon	❌	❌	❌
Browser IDE + SSH + VS Code + JetBrains	✅	Partial	✅	✅
Integrated access-controlled HTTPS staging server	✅	❌	❌	❌
Works on your laptop	✅	❌	Partial	❌
Open source	✅ Apache 2.0	❌	Partial	✅ AGPL

Dockside’s sweet spot: teams that want Codespaces-style devcontainers without the cloud lock-in, and teams that want to run AI coding agents safely and privately on their own infrastructure.

Features

Core features:

• Instantly launch disposable devcontainers: one per task, bug, feature, design iteration, or AI agent session.
• Powerful IDE bundle including OpenVSCode Server and Theia, plus first-class SSH and support for VS Code Remote Development using SSH or JetBrains development over SSH.
• AI-ready devcontainers: Claude Code, OpenAI Codex, GitHub Copilot and other AI tools and CLIs run natively inside every devcontainer’s integrated IDE. Isolate each AI agent session in its own container for safe, auditable agentic development.
• An access-controlled HTTPS reverse proxy automatically provisioned for every devcontainer, with separately configurable domain name prefixes for each subservice.
• SSH server with automated authorized_keys provision for every devcontainer.
• User authentication and access control to running devcontainers and their web services.
• Fine-grained user and role-based access control to devcontainer functionality and underlying system resources.
• Launch devcontainers from stock Docker images, or from your own.
• Root access within devcontainers, so developers can upgrade their environment and install operating system packages when and how they need.
• Bundled GitHub CLI (gh) with per-user token support for seamless gh pr checkout and other GitHub operations.

Benefits for developers:

• Code in a clone of your production environment, avoiding troublesome deploy-time errors and bugfixing.
• Switch between and hand over tasks instantly. No more laborious branch switching, or committing code before it’s ready. git stash will be a thing of the past.
• Work from anywhere. All you need is a browser. Or connect with VS Code, JetBrains, or any other IDE capable of remote development over SSH. Or SSH in directly and use your favourite terminal editor or toolchain. You choose.
• Run AI coding agents — Claude Code, Codex, GitHub Copilot — safely inside isolated devcontainers. Each agent session is self-contained, and coming-soon firewall controls let you define exactly what AI tools can reach on the network.
• Unifying on an IDE within a team can deliver great productivity benefits through improved knowledge-share and better choices of plugins and tooling.
• SSH access facilitates use of any terminal editor or command line tool and seamless VS Code remote development via the Remote SSH extension.
• Develop against production databases (or production database clones) when necessary.

Benefits for code reviewers:

• Access your colleagues’ devcontainers directly for code review.
• No more staring at code wondering what it does, or time-consuming setup, when their code is already running.
• Annotate their code directly with your comments as to points they should address.
• To save time, when you know best, apply and test your own fixes directly to their code.

Benefits for product managers and senior management:

• High visibility of product development progress. Access always-on application revisions and works-in-progress, wherever you are in the world.
• Every feature branch can have its own running environment — share a link with stakeholders to review work in progress without waiting for a dedicated staging deployment.

Advanced features:

• Runtime agnostic: use runC (Docker’s default), Sysbox (for Docker-in-Dockside devtainers), gVisor (for sandboxed kernel isolation), or RunCVM (for full KVM VMs on amd64); see Alternative runtimes.
• Apply Docker system resource limits to devtainers, and communicate available system resources to devtainers using LXCFS.
• Support for launching multi-architecture devtainers using qemu-user-static.
• Firewall or redirect outgoing devcontainer traffic using custom Docker networks — useful for isolating AI agent network access or mirroring production network topologies.
• Access Dockside devtainers via multiple domain names, when needed to stage or simulate multi-domain web applications.
• Command-line interface (dockside CLI) for scripting, automation, and CI/CD integration.
• Autodetection of available runtimes, networks and IDEs from the host environment.

Host requirements

Dockside is supported on Intel (amd64/x86) and arm64 (Apple M1-5, Raspberry Pi 64-bit) hardware platforms, via a multiarch Docker image that contains native binary implementations of Dockside for both architectures.

Dockside is tested on:

• Intel (amd64/x86) platforms running Debian Linux and Docker Engine (via the docker-ce package suite)
• MacOS (amd64/x86 and Apple M1-5) running Docker Desktop
• Intel Windows 10 running Docker Desktop
• Raspberry Pi (arm64) running Raspberry Pi OS 64-bit and Docker Engine (via the docker-ce package suite)

Dockside requires a host with a minimum of 1GB memory.

Getting started

Installing Docker

Dockside is designed to be installed using Docker. To install Docker for your platform, go to https://www.docker.com/

Quick Start — Launch locally with integrated SSL certificate

The fastest way to get started with Dockside is to run it on your local machine. This is ideal for solo developers working on multiple web projects simultaneously — spin up a devcontainer per branch, per project, per experiment, or per AI agent session, all accessible from your browser.

Using docker compose (recommended):

curl -o docker-compose.yml https://raw.githubusercontent.com/newsnowlabs/dockside/refs/heads/main/docker-compose.yml && \
mkdir -p ~/.dockside && \
docker compose up -d

# Read off autogenerated 'admin' user credentials
docker compose logs 2>&1 | grep 'Sign in'

Using docker run:

mkdir -p ~/.dockside && \
docker run -d --name dockside \
  -v ~/.dockside:/data \
  --mount=type=volume,src=dockside_ide,dst=/opt/dockside \
  --mount=type=volume,src=dockside_hostkeys,dst=/opt/dockside/host \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -p 443:443 -p 80:80 \
  --security-opt=apparmor=unconfined \
  newsnowlabs/dockside --ssl-builtin

# Read off autogenerated 'admin' user credentials
docker logs dockside 2>&1 | grep 'Sign in'

Note:

• While AppArmor must be disabled for the Dockside container (unless a customised profile exists), Dockside does NOT disable AppArmor for devcontainers it manages, unless your profiles specifically configure that.
• The built-in SSL certificate covers *.local.dockside.dev which resolves to 127.0.0.1 and is intended for local use only.

Once Dockside is running:

1. In your browser, navigate to https://www.local.dockside.dev/. Sign in with the username admin and the auto-generated password output to the terminal, then follow the instructions displayed on-screen.
2. Authenticate the CLI (optional — for CI/CD and management via terminal): install from the Dockside repository and log in to your local instance:

   dockside login --server https://www.local.dockside.dev --nickname local
   

   Enter your admin credentials when prompted. Your session is saved to ~/.config/dockside/ and reused by subsequent dockside commands. See the Dockside CLI README for full installation options and available commands.
3. In the Dockside UI, click Launch, and pick an example profile (e.g. Stock Image - Ghost) to launch your first trial devcontainer — this confirms everything is working.
4. Next, register your team members and configure profiles to tailor the available devcontainer types for your projects — through the Admin UI (/admin), the dockside CLI, or by editing the config files directly. See Setup below for a guided overview and the full configuration reference here.

Launch on a public domain with auto-generated SSL

To share devtainers with your team — or access them from anywhere — deploy Dockside on an internet-connected server with a public domain name and a LetsEncrypt wildcard SSL certificate generated automatically on startup.

In order for Dockside to auto-generate a public SSL certificate using LetsEncrypt, the server must be delegated responsibility for handling public internet DNS requests for your chosen domain, and must accept UDP requests on port 53. So:

1. Delegate the domain to the server running Dockside by installing the following two DNS records for <my-domain>:

<my-domain> A <my-server-ip>
<my-domain> NS <my-domain>

These records tell the public DNS infrastructure that DNS requests for <my-domain> should be forwarded to <my-server-ip>.

2. Launch Dockside as per Quick Start above, except modify the docker-compose.yml file (or docker run) command from --ssl-builtin to --ssl-letsencrypt --ssl-zone <my-domain>

Assuming you have provisioned <my-domain> correctly, Dockside will use LetsEncrypt to generate a public SSL certificate on startup and to regenerate the certificate periodically to ensure it remains current.

3. In your browser, navigate to https://www.<my-domain>/. To view the launch logs and obtain the auto-generated admin user password, run docker logs dockside. Sign in with the username admin and the displayed password, then follow the instructions displayed on-screen.

Advanced Launch Options

Dockside is designed to support multiple custom networks, each with their own firewall rules and security profile. Dockside then makes it easy to assign the right network to the right dev containers for the project under development. See multi network docker compose examples.

For self-signed, self-supplied SSL, Google Cloud Deployment Manager, and Terraform launch configurations, see Advanced Launch Options.

Setup

Dockside configuration lives under ~/.dockside/config/ on the host (mounted at /data/config/ inside the container). Config files are plain JSON (with // comments allowed) and are auto-reloaded on change — most settings take effect immediately without restarting Dockside.

Getting set up involves three main steps:

• Profiles: define the types of devcontainer your team can launch — which Docker images, networks, runtimes, and IDE options are available. Dockside ships several example profiles (400-linux.json, 300-nginx.json, 900-dockside.json, and others) to get you started. Manage them through the Admin UI (/admin/profiles, requires manageProfiles) or the dockside profile CLI; editing the .json files directly remains an advanced/offline option.
• Users and Roles: manage team members and roles through the Admin UI (/admin/users, /admin/roles, requires manageUsers) or the dockside user / dockside role CLI — assign a role (admin or a custom role) to control what each user can do and which profiles they can deploy. The manageUsers / manageProfiles permissions delegate administration to non-admin roles. The underlying users.json / passwd / roles.json files can still be edited directly as an advanced/offline method.
• SSH keys: add each user’s SSH public key(s) — via the Account UI (their own keys), the Admin UI, or the dockside user CLI — so Dockside auto-populates ~/.ssh/authorized_keys in every devcontainer they own or are shared on. Users then follow the one-click SSH Setup instructions in the Dockside UI to configure their ~/.ssh/config and install the wstunnel helper. After that, SSHing into any devcontainer — and using VS Code Remote SSH or JetBrains Remote Development — works seamlessly with no extra steps.

For the full configuration reference see Configuring and administering Dockside, including config.json, Roles, Profile routers and Access control.

Usage

The Dockside UI is intentionally simple: click Launch to create a new devcontainer from a profile, configure it, and you’re running in seconds. The rest of the workflow — opening an IDE, starting an SSH session, sharing a devcontainer with a colleague, setting access modes on its exposed services — is a click or two away.

Key workflow points:

• Launching a devcontainer: choose a profile, select a Docker image, set your network and runtime, optionally specify a git branch or other profile options, then click Launch.
• Using the IDE: open Theia or OpenVSCode Server directly in your browser. AI coding tools (Claude Code, Codex, Copilot) run natively inside the IDE. The bundled gh CLI authenticates automatically when you have a gh_token configured in your user profile.
• SSH access: one-click SSH from the Dockside UI, or SSH in directly from any terminal. Works with VS Code Remote SSH and JetBrains Remote Development out of the box once SSH client setup is complete.
• Outbound SSH for git operations: add a user’s keypair(s) — via the Account/Admin UI or the dockside user CLI — and Dockside automatically loads them into the integrated ssh-agent on every devcontainer launch — enabling git push / git pull to GitHub, GitLab, or any SSH remote from the IDE or terminal, with no manual ssh-add required.
• Sharing and access control: share a devcontainer with teammates as developers or viewers, and set per-service access levels (owner-only, team, or public URL).

For the full UI and CLI reference see Usage.

CLI

The dockside CLI is a zero-dependency Python 3.6+ command-line interface for managing devtainers programmatically, suitable for scripting and CI/CD pipelines. See the Dockside CLI README for full documentation.

Security

See Securing profiles and devtainers

Upgrading

Dockside upgrades the system binaries and IDEs available to devcontainers automatically, whenever a newer version of Dockside is launched (assuming the v4.0.0+ docker run or docker-compose.yml syntax that features a named /opt/dockside volume mount).

See Upgrading Dockside for advanced upgrade strategies.

Extensions

• LXCFS – allows processes within devtainers to correctly report their own cpu, memory, and disk available resources and usage
• Multi-architecture devtainers – support for devtainers running non-amd64 processor architectures
• Alternative runtimes – Sysbox (Docker-in-Dockside devtainers), RunCVM (KVM VMs on amd64), gVisor (sandboxed kernel isolation)
• Backups – strategies for backing up devtainers
• Integrated SSH server support – allows seamless one-click SSH access to devtainers from the command line and accessing devtainers using VS Code
• Local ssh-agent support – to allow use of git functionality across Dockside IDEs (like Git: Push and Git: Pull) or other SSH-based commands accessible within their UIs or terminals

Case study: Dockside in production at NewsNow

Dockside was built at NewsNow and has been the daily development platform for the entire NewsNow engineering team for years. Read how it’s used in production across all aspects of web application and back-end development, staging, and acceptance testing for newsnow.co.uk and newsnow.com — a real-world, high-traffic platform built and maintained entirely inside Dockside devcontainers.

Roadmap

Near-term priorities include:

• Network firewall management: per-Docker-network configurable outbound firewall rules, enabling safe AI agent sandboxing without elevated container capabilities — assign a devcontainer to a restricted network to define exactly what AI tools can reach.
• Terraform launch support: first-class infrastructure-as-code deployment for teams managing Dockside at scale.

Beyond that, the roadmap is shaped by what our users most need. We’d love to hear from you — tell us what would be most valuable to add next.

For the full picture, see our draft roadmap.

Developing

See Developing Dockside to learn more about how to go about developing Dockside within Dockside, the Dockside application components and building Dockside images.

Bugs, issues and support

If you are experiencing an issue or believe you may have found a bug, please raise an issue or contact via on the NewsNow Labs Slack Workspace.

Contributing

If you would like to contribute a bugfix, patch or feature, we’d be delighted.

Please just raise an issue or contact us on our NewsNow Labs Slack Workspace.

Contact

Github: Raise an issue

Slack: NewsNow Labs Slack Workspace

Email: [email protected]

We are typically available Monday-Friday, 9am-5pm London time.

Thank you

Thank you very much for using and/or contributing and/or spreading the word about Dockside. We hope you find it helps your team be more and more productive.

Credits

Thanks to Struan Bartlett for conceiving the model of iterative web development through the use of ready-built, stageable and disposable development environments running web-based IDEs, and for leading the development of Dockside.

Thanks also to other members of the NewsNow development team for contributing the Dockside Vue client, design and architectural ideas, support and advice, code and code-reviews; for coining the term devtainers; and for the Dockside logo concept.

Thanks also to the entire design and development, editorial and testing teams at NewsNow for so enthusiastically adopting containerised development working practices and for subjecting Dockside to so many years of robust use (and abuse) during the course of their daily iterative development, evaluation and testing of the NewsNow platform - and proving the value of this development model.

Thanks last but not least to NewsNow, The Independent News Discovery Platform, for sponsoring the development of Dockside.

More credits

The Dockside multiarch build is built thanks to Depot and we’re grateful for their support.

Licence and legals

This project (known as “Dockside”), comprising the files in this Git repository, is copyright 2017-2026 NewsNow Publishing Limited and contributors.

Dockside is an open-source project licensed under the Apache License, Version 2.0 (the “License”); you may not use Dockside or its constituent files except in compliance with the License.

You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

N.B. In order to run, Dockside relies upon other third-party open-source software dependencies that are separate to and independent from Dockside and published under their own independent licences.

Dockside Docker images made available at https://hub.docker.com/repository/docker/newsnowlabs/dockside are distributions designed to run Dockside that comprise: (a) the Dockside project source and/or object code; and (b) third-party dependencies that Dockside needs to run; and which are each distributed under the terms of their respective licences.

Trade marks

Dockside and devtainer are trade marks of NewsNow Publishing Limited. All rights reserved.