GitHub - Tomnerb/Dockiva: Open-source OrbStack alternative: run Docker containers on Apple Silicon without a Linux VM. Desktop app for macOS, Linux, and Windows.

The open-source OrbStack alternative.
Run Docker containers on your Mac without a Linux VM.

Why Dockiva

No Linux VM on Apple Silicon. Dockiva Engine runs container code directly on the CPU through Hypervisor.framework. There is no guest kernel to boot and no VM holding gigabytes of RAM.
Fast where you feel it. docker run starts in about 80 ms, and builds keep pace with OrbStack. See benchmarks.
Works with the tools you have. The plain docker CLI, docker compose, and docker build, including BuildKit features such as RUN --mount and heredocs.
Open source. Apache 2.0. No license fee, no account, no telemetry.
A focused desktop app. Containers, Compose projects, logs, terminal, stats, images, volumes, and networks, plus a menu-bar controller.
Your data stays where it is. Dockiva never takes over Docker Desktop or another engine. Each engine keeps its own store and Docker context.

Install

macOS (Apple Silicon): download the signed and notarized Dockiva-<version>-macOS-arm64.dmg, drag Dockiva to Applications, and open it. The engine starts on its own.

You also need the Docker CLI. If you don't have it:

brew install docker

For docker compose, also run brew install docker-compose and follow the setup note it prints.

Intel Macs, Linux, and Windows: download the matching archive or installer from the latest release. See platform status for what each one supports.

Quickstart

docker context use dockiva
docker run --rm -p 8080:80 nginx

Open http://localhost:8080. Your existing Docker setup is untouched; switch back any time with docker context use default.

Benchmarks

Dockiva Engine compared with OrbStack on the same Apple Silicon Mac (medians of three alternating rounds, development build, November 2026):

Workload	Dockiva	OrbStack
`docker run` container start	82 ms	246 ms
`go build`	3.47 s	3.49 s
`npm install` (bind-mounted project)	0.46 s	0.58 s
Postgres `pgbench` TPC-B, 10 clients	3,824 tps	1,065 tps
Process spawn (Node `spawnSync`)	1.2 ms	0.34 ms

OrbStack is still faster at spawning processes; that work is in progress. The pgbench write numbers are not a like-for-like durability comparison; see DOCKIVA-ENGINE.md for details and methodology.

Project status

Dockiva is young and moving fast. The macOS Apple Silicon engine is the main focus; Windows support is experimental. It runs linux/arm64 images today, and linux/amd64 support is in progress. Kubernetes is not supported. Please open an issue when something breaks.

Dockiva compared with OrbStack and Docker Desktop

Capability	Dockiva	OrbStack	Docker Desktop
License	Open source (Apache 2.0)	Proprietary; paid for commercial use	Proprietary; paid for larger companies
How containers run on Apple Silicon	Directly on the CPU, no Linux VM	Lightweight Linux VM	Linux VM
Host platforms	macOS, Linux, Windows (experimental)	macOS	macOS, Linux, Windows
Docker CLI, Compose, and builds	Yes	Yes	Yes
Kubernetes	No	Yes	Yes
Linux machines	No	Yes	No
Runs alongside other engines	Yes, separate store and Docker context	Yes, with migration	Uses its own context

Choose Dockiva for a free, open-source, VM-free Docker engine on Apple Silicon. Choose OrbStack or Docker Desktop if you need Kubernetes, Linux machines, or a long-established product today.

Features

Container start, stop, restart, delete, logs, terminal, and inspect tools
Docker Compose import, grouping, project actions, builds, and rebuilds
Live CPU, memory, PID, port, and networking information
Image, volume, network, disk-usage, and prune tools
Menu-bar and tray controls with event-driven refresh
Light and dark appearance
Explicit runtime selection: Dockiva Engine or an existing Docker endpoint

Runtime architecture

                       Dockiva UI and Go core
                                  │
                          ContainerRuntime
                                  │
              ┌───────────────────┼───────────────────┐
              │                   │                   │
            Linux               macOS               Windows
              │                   │                   │
        containerd/runc      Dockiva Engine           WSL2
                       (Hypervisor.framework,         │
                         no Linux VM; or a      Dockiva guest
                      Virtualization.framework        │
                          VM as an option)    dockerd/containerd/runc

External Docker and Moby endpoints remain available on supported platforms. Dockiva Native exposes its own Docker-compatible API endpoint; it is a separate engine and never overwrites the selected External Docker endpoint.

Platform status

Platform	Backend	Status
Linux	Direct containerd in the `dockiva` namespace	Implemented; CNI networking requires one-time helper installation
macOS (Apple Silicon)	Dockiva Engine on Hypervisor.framework, no Linux VM	Default for new installations; `linux/arm64` images
macOS	Apple `Virtualization.framework` VM	Optional; requires Linux-generated kernel and root filesystem assets
Windows	Dedicated Dockiva WSL2 guest	Experimental; native runtime parity remains in progress
All	External Docker/Moby endpoint	Supported

Docker Compose orchestration currently requires the Docker runtime. The macOS native guest now includes the Docker Engine foundation (dockerd over its own local socket); target-macOS validation is still required before release.

Docker contexts and migration

Dockiva Native and an existing Docker Desktop/System Docker installation are separate container stores. Use separate Docker contexts rather than trying to merge live engines:

docker context: dockiva       -> Dockiva Native
docker context: desktop-linux  -> Docker Desktop

The planned Migrate Docker Data to Dockiva flow is explicitly opt-in. It will inventory images, containers, volumes, and Compose projects; show disk and compatibility checks; copy supported data to Dockiva Native; and verify the result. It will never delete, alter, or silently switch the source Docker engine. Persistent-data migration requires macOS/Windows target validation and is not claimed as complete by this Linux build.

Build requirements

Go 1.26.3 or newer
Node.js and npm
Wails v3 beta.19

Install the matching Wails CLI:

go install github.com/wailsapp/wails/v3/cmd/wails3@v3.0.0-beta.19

Then install frontend dependencies:

cd frontend
npm ci
cd ..

Development

Run the Wails development environment:

wails3 task dev

The reliable Linux GTK3 path is:

wails3 build -tags gtk3
./bin/dockiva

Frontend-only development:

cd frontend
npm run dev

Build

Versioning and in-app updates

VERSION is the product-version source of truth. It contains a semantic version without the v prefix, for example:

0.1.0

Production builds embed that version together with the current Git commit and UTC build date. The macOS build also writes the version into the app bundle; CFBundleVersion defaults to the Git commit count and may be overridden in CI:

DOCKIVA_BUILD_NUMBER=42 ./scripts/build-macos.sh arm64 \
  --guest-assets ./macos-guest

The Engine Settings page shows the installed version and includes Check for Updates. Dockiva reads the latest public release from Tomnerb/Dockiva and compares its vX.Y.Z tag with the installed version. If an update exists, Update & Restart downloads the matching archive inside the app, verifies it against the release's SHA256SUMS, stages the replacement, quits Dockiva, atomically replaces the installed app, and launches the new version. The original installer remains available as a manual fallback.

For a release, update VERSION, commit it, build the release installers, then publish a GitHub release with the matching tag, such as v0.2.0. A macOS release build produces all three files needed for distribution:

dist/macos-ARCH/Dockiva-VERSION-macOS-ARCH.dmg
dist/macos-ARCH/Dockiva-VERSION-darwin-ARCH.zip
dist/macos-ARCH/SHA256SUMS

Upload the .dmg, updater .zip, and SHA256SUMS to the same GitHub Release. The darwin and architecture tokens in the updater archive name are required so Dockiva selects the correct asset. Never publish an updater archive without its matching checksum file. When Apple credentials are configured, the archive contains the signed, notarized, and stapled Dockiva.app. An unsigned release instead contains an ad-hoc-signed app and may be blocked by Gatekeeper until the user explicitly allows it. Updating VERSION always requires rebuilding the release artifacts.

Automated GitHub release

The release workflow runs when a stable vX.Y.Z tag is pushed. It verifies that the tag matches VERSION, runs the frontend and Go tests, builds the macOS native guest, produces signed-or-unsigned macOS and Windows releases, and the Linux updater archive, creates one combined SHA256SUMS, and publishes the GitHub Release. It can also be rerun manually from Actions → Release → Run workflow with an existing tag. The current automated targets are macOS arm64 (Dockiva Native), macOS amd64 (external Docker engine), Windows amd64, and Linux amd64/arm64.

Configure these optional GitHub Actions environment secrets to sign releases:

Secret	Value
`MACOS_CERTIFICATE`	Optional: base64-encoded Developer ID Application `.p12`
`MACOS_CERTIFICATE_PASSWORD`	Password used when exporting the `.p12`
`MACOS_SIGN_IDENTITY`	Full `Developer ID Application: … (TEAM_ID)` identity
`APPLE_ID`	Apple Account used for notarization
`APPLE_TEAM_ID`	Apple Developer team ID
`APPLE_APP_PASSWORD`	App-specific password used by `notarytool`
`WINDOWS_CERTIFICATE`	Optional: base64-encoded Authenticode `.pfx`
`WINDOWS_CERTIFICATE_PASSWORD`	Optional: password for the `.pfx`

Create GitHub environments named release-macos, release-windows, and release-publish. Store platform signing secrets in their matching environment instead of as unrestricted repository secrets. Restrict deployments to version tags matching v*.*.*; optional required reviewers add a manual release gate, while leaving reviewers empty preserves fully automatic tagged releases. Protect main and release tags, and enable private vulnerability reporting under Settings → Security. The workflow pins third-party actions to reviewed commit SHAs so a mutable action tag cannot change release code.

Then publish a release by changing and committing VERSION before creating the matching tag:

git add VERSION
git commit -m "chore(release): prepare v0.2.0"
git push origin main
git tag v0.2.0
git push origin v0.2.0

The six Apple secrets must either all be configured or all be absent. Without them, the workflow publishes an ad-hoc-signed macOS app and unsigned DMG; the updater still verifies SHA256SUMS, but Gatekeeper may block first launch. Add all six secrets later to enable Developer ID signing and notarization.

The two Windows secrets are optional, but they must either both be configured or both be absent. Without them, the workflow publishes an unsigned executable and installer; in-app updates still require and verify SHA256SUMS, but Windows shows an unknown publisher and may display SmartScreen warnings. Add the two secrets later to enable Authenticode signing without changing the release flow.

The release is published only after every platform job succeeds. Windows uses a per-user installer under %LOCALAPPDATA% so the in-app updater can replace the packaged executable without an administrator prompt. Linux self-update works when the extracted dockiva binary is installed in a user-writable location, such as ~/.local/bin; system package upgrades should continue through the system package manager.

macOS

An external-Docker-only build needs only macOS. Use arm64 for Apple silicon or amd64 for Intel:

./scripts/build-macos.sh arm64 --external-only
./scripts/build-macos.sh amd64 --external-only

The native engine additionally needs vmlinux and rootfs.ext4. Generate them once on Linux:

./scripts/build-macos-guest-assets-linux.sh

Copy the resulting macos-guest directory to the Mac, then build and optionally install:

./scripts/build-macos.sh arm64 \
  --guest-assets /path/to/macos-guest \
  --install

Output:

dist/macos-arm64/Dockiva.app

The bundled native engine currently supports Apple silicon only. Intel Mac builds use an external Docker-compatible engine, such as Docker Desktop. The --install option copies the completed application to ~/Applications/Dockiva.app; without it, the application remains in dist/ and can be copied to Applications manually.

Create a macOS DMG installer

Build the application first, then create the DMG from the completed app bundle:

./scripts/build-macos.sh arm64 \
  --guest-assets /path/to/macos-guest
wails3 task darwin:create:dmg

For an external-Docker-only DMG:

./scripts/build-macos.sh arm64 --external-only
wails3 task darwin:create:dmg

Output:

bin/dockiva.dmg

Use darwin:create:dmg after build-macos.sh. The higher-level darwin:package:dmg task rebuilds the application and can replace the native app bundle before the VMM helper and guest assets are injected. A native DMG contains dockiva-vmm, vmlinux, and rootfs.ext4; an external-only DMG is smaller but requires an existing Docker or Moby endpoint.

Verify and open the image on macOS with:

hdiutil verify bin/dockiva.dmg
open bin/dockiva.dmg

Development and unsigned-release bundles are ad-hoc signed. Public distribution is smoother and establishes publisher identity when an Apple Developer ID Application certificate, hardened runtime, notarization, and stapling are used. Without them, clearly label the release unsigned and expect Gatekeeper warnings.

Create an unsigned DMG and updater archive with:

./scripts/build-macos.sh arm64 \
  --guest-assets ./macos-guest \
  --unsigned-release

Create a signed and notarized release DMG

Install a Developer ID Application certificate and its private key in the login keychain. Store notarization credentials once; use an app-specific password instead of the Apple Account password:

xcrun notarytool store-credentials "dockiva-notary" \
  --apple-id "YOUR_APPLE_ID" \
  --team-id "YOUR_TEAM_ID" \
  --password "YOUR_APP_SPECIFIC_PASSWORD"

Then run the release build with the exact identity shown by security find-identity -v -p codesigning:

./scripts/build-macos.sh arm64 \
  --guest-assets ./macos-guest \
  --release \
  --sign-identity "Developer ID Application: YOUR NAME (TEAM_ID)" \
  --notary-profile "dockiva-notary"

The script signs the nested VMM helper with its Virtualization entitlement, signs the application with hardened runtime and a secure timestamp, notarizes and staples the application, then creates, signs, notarizes, and staples bin/dockiva.dmg. Credentials remain in Keychain and are never written to the repository. DOCKIVA_SIGN_IDENTITY and DOCKIVA_NOTARY_PROFILE may be used instead of their corresponding command-line options.

Linux

./scripts/build-linux.sh amd64
./scripts/build-linux.sh arm64

Output:

dist/linux-amd64/dockiva
dist/linux-arm64/dockiva

Install direct-containerd networking once when using the native Linux runtime:

sudo ./scripts/install-containerd-networking.sh

Windows

Cross-build the executable from macOS or Linux:

./scripts/build-windows.sh amd64

To build the current NSIS application installer, run the following commands on Windows with Wails and NSIS installed:

wails3 build GOOS=windows GOARCH=amd64
.\scripts\package-windows.ps1

The generated installer is written under bin/; its name follows the Wails application configuration, normally dockiva-amd64-installer.exe. This installer installs the desktop application, WebView2 runtime when needed, Start Menu and desktop shortcuts, and an uninstaller. It does not currently provision the native WSL2 guest automatically.

The dedicated WSL2 guest root filesystem must currently be generated on Linux:

./scripts/build-windows-wsl-rootfs-linux.sh

Copy dist/windows-wsl/dockiva-wsl-rootfs.tar to the Windows computer and provision the dedicated Dockiva WSL2 distribution from PowerShell:

.\scripts\check-wsl-windows.ps1
.\scripts\install-dockiva-wsl.ps1 `
  -Rootfs C:\path\to\dockiva-wsl-rootfs.tar

Run these scripts only after WSL2 is enabled. The setup imports an isolated distribution named Dockiva under %LOCALAPPDATA%\Dockiva\wsl; it does not modify an existing Ubuntu or other user-managed WSL distribution.

Planned Windows installer variants

The intended release packaging has two explicit choices:

Dockiva-External-Setup.exe installs the desktop application for use with an existing Docker or Moby endpoint and does not require WSL2.
Dockiva-Native-Setup.exe bundles the Dockiva root filesystem and offers to provision the dedicated WSL2 runtime with the user's consent.

The native installer should detect WSL2, explain any required Windows feature or restart, preserve the Dockiva distribution and container data during normal app upgrades, and never unregister the distribution during uninstall without a separate explicit confirmation. When a supported signing service is available, public releases should Authenticode-sign both the application executable and installer. Unsigned releases remain checksummed but Windows identifies them as coming from an unknown publisher and may show SmartScreen warnings.

Until that integrated native installer is implemented and validated on Windows, use the NSIS application installer and the separate WSL provisioning command above. The Windows native container runtime remains experimental.

Validation

go test ./...

cd frontend
npm run build

Architecture checks are also available:

./scripts/verify-engine-architecture.sh
./scripts/verify-runtime-architecture.sh

Project structure

frontend/        Vue 3 and TypeScript desktop interface
cmd/             Guest and networking helper commands
native/          macOS VMM and Windows launcher
scripts/         Build, package, install, and validation scripts
build/           Wails platform packaging configuration
engine_*.go      Platform engine lifecycle implementations
runtime_*.go     Runtime-neutral Docker/containerd adapters

Milestone-specific implementation decisions and known limitations are retained in docs/MILESTONES.md.

Dockiva Engine

New Apple Silicon installations default to the bundled ARM64 Dockiva Engine, which starts automatically without terminal setup. Existing engine choices are preserved. Containers run natively under Hypervisor.framework where available (no guest kernel), with an interpreter as fallback. See DOCKIVA-ENGINE.md for capabilities, limits, and the developer test builds.

Contributing

Dockiva is open source under the Apache License 2.0. Contributions are welcome; read CONTRIBUTING.md before opening a pull request. Report suspected vulnerabilities privately according to SECURITY.md.

Every pull request runs the frontend build and Go test suite. Dependabot checks Go, npm, and GitHub Actions dependencies weekly.

The long-term macOS design (a SwiftUI/AppKit app over a Go daemon and C runtime) is described in docs/FINAL-ARCHITECTURE-V1.md.

Name		Name	Last commit message	Last commit date
.github		.github
assets		assets
build		build
cmd		cmd
docs		docs
frontend		frontend
macos		macos
native		native
scripts		scripts
.gitignore		.gitignore
CONTRIBUTING.md		CONTRIBUTING.md
DOCKIVA-ENGINE.md		DOCKIVA-ENGINE.md
DOCKIVA_ENGINE_REF		DOCKIVA_ENGINE_REF
LICENSE		LICENSE
README.md		README.md
SECURITY.md		SECURITY.md
Taskfile.yml		Taskfile.yml
VERSION		VERSION
app_settings.go		app_settings.go
app_settings_test.go		app_settings_test.go
app_version.go		app_version.go
app_version_test.go		app_version_test.go
containerd_id.go		containerd_id.go
core_api.go		core_api.go
core_api_test.go		core_api_test.go
core_update_test.go		core_update_test.go
docker_cli_context.go		docker_cli_context.go
docker_cli_context_test.go		docker_cli_context_test.go
docker_extra_service.go		docker_extra_service.go
docker_migration_engine.go		docker_migration_engine.go
docker_migration_engine_test.go		docker_migration_engine_test.go
docker_migration_transport_nonlinux.go		docker_migration_transport_nonlinux.go
docker_platform.go		docker_platform.go
docker_platform_test.go		docker_platform_test.go
docker_service.go		docker_service.go
docker_service_test.go		docker_service_test.go
engine_autorecovery.go		engine_autorecovery.go
engine_autostart_linux.go		engine_autostart_linux.go
engine_autostart_other.go		engine_autostart_other.go
engine_common.go		engine_common.go
engine_darwin.go		engine_darwin.go
engine_darwin_test.go		engine_darwin_test.go
engine_linux.go		engine_linux.go
engine_vmfree.go		engine_vmfree.go
engine_vmfree_test.go		engine_vmfree_test.go
engine_windows.go		engine_windows.go
external_engine_darwin.go		external_engine_darwin.go
external_engine_other.go		external_engine_other.go
go.mod		go.mod
go.sum		go.sum
host_container_storage.go		host_container_storage.go
host_container_storage_darwin.go		host_container_storage_darwin.go
host_container_storage_other.go		host_container_storage_other.go
host_container_storage_test.go		host_container_storage_test.go
live_create_test.go		live_create_test.go
main.go		main.go
network_helper_client_linux.go		network_helper_client_linux.go
runtime_candidates_other.go		runtime_candidates_other.go
runtime_common.go		runtime_common.go
runtime_containerd_darwin.go		runtime_containerd_darwin.go
runtime_containerd_linux.go		runtime_containerd_linux.go
runtime_containerd_tools_linux.go		runtime_containerd_tools_linux.go
runtime_developer_tools.go		runtime_developer_tools.go
runtime_docker.go		runtime_docker.go
runtime_stream_bridge.go		runtime_stream_bridge.go
runtime_vmfree.go		runtime_vmfree.go
runtime_vmfree_events_test.go		runtime_vmfree_events_test.go
runtime_vmfree_test.go		runtime_vmfree_test.go
tray_controller.go		tray_controller.go
update_provider.go		update_provider.go
update_provider_test.go		update_provider_test.go

Navigation Menu

Repository navigation

About

Repository files navigation

Why Dockiva

Install

Quickstart

Benchmarks

Project status

Dockiva compared with OrbStack and Docker Desktop

Features

Runtime architecture

Platform status

Docker contexts and migration

Build requirements

Development

Build

Versioning and in-app updates

Automated GitHub release

macOS

Create a macOS DMG installer

Create a signed and notarized release DMG

Linux

Windows

Planned Windows installer variants

Validation

Project structure

Dockiva Engine

Contributing

About

Releases

Packages

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

Why Dockiva

Install

Quickstart

Benchmarks

Project status

Dockiva compared with OrbStack and Docker Desktop

Features

Runtime architecture

Platform status

Docker contexts and migration

Build requirements

Development

Build

Versioning and in-app updates

Automated GitHub release

macOS

Create a macOS DMG installer

Create a signed and notarized release DMG

Linux

Windows

Planned Windows installer variants

Validation

Project structure

Dockiva Engine

Contributing

About

Topics

Resources

Contributing

Security policy

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages