Stackie

Fully Native Local Development Stacks

curl -fsSL https://stackie.dev/install.sh | sh

Features

Run services natively on macOS, Windows, and Linux without the overhead of virtualisation.Simple, secure, and blazing fast.

Batteries Included

Launch complete development environments with a single command. No configuration. No virtualization.

Supabase

Firebase alternative

A complete local Supabase environment matching npx supabase start, with PostgreSQL, auth, REST API, realtime subscriptions, file storage, and a full dashboard. All services. One command.

10 services~200MB idleAPI on :54321Studio on :54323
stackie
$stackie up -s supabase

Included services

Cache CDN

Stackie blocks are pre-compiled and served fromCache, our curated edge network, so installs and updates land in seconds on every platform we support.

Curated, pre-built, fast

Cache is a curated repository of Stackie's supported blocks, maintained by the Stackie team. Source packages are pre-compiled for every platform we ship for, so a fresh install or an update is a single CDN download without a source build or a wait for a compile on your laptop.

  • Compatibility-checked

    Every block in the cache catalogue is built and tested against the current Stackie runtime before it ships. If a version is on the CDN, it works.

  • Provenance you can verify

    Sources come from canonical upstream URLs we publish in each block's YAML, and every artefact is SHA-256 checksum-verified at install time. The CDN is a transparent layer in front of upstream, and Stackie falls back to the original source if a checksum ever fails to match.

  • Pre-compiled per platform

    Whether you run Postgres on a base-model M-series, Mailpit on an arm Linux box, or Supabase Studio on Windows, each Stackie block uses a platform-native binary without source compilation.

  • Edge-served, globally

    Backed by a global CDN so the install bytes come from the nearest edge, not a single mirror on the other side of the planet. New machine, new stack, ready in seconds.

Platforms

macOS (arm64)macOS (x86_64)Linux (x86_64)Linux (arm64)Windows (x86_64)
Cache
read-only · public
postgresv18.3
supabasev2.x
redisv7.x
mailpitv1.x
miniovRELEASE
+ the rest of the catalogue at /docs/blocks

One pull, every platform

$ stackie up -b postgres
↳ pulled from Cache (4.2 MB)
 postgres v18.3 ready in 1.1s

Sips battery life

Stackie services live in megabytes, not gigabytes, but the bigger win is everything else that follows from running native processes instead of a Linux VM.

Performance optimised everywhere

Once your services are real OS processes instead of container guests in a hidden Linux VM, every layer underneath them gets out of the way. The OS schedules them, the filesystem doesn't proxy, your debugger sees them as PIDs, and the kernel reclaims memory the moment they're done with it.

  • Fans off, battery up

    Idle Stackie services idle the way native processes do because the OS schedules them out, the CPU stays low, and the fans stay quiet, and the laptop sleeps when you close the lid. No guest kernel running underneath to keep the lights on.

  • Filesystem at native speed

    No VirtioFS, no 9P, no virtualised file boundary between your code and your services. npm install, test runs, and migrations move at the speed of your actual disk, and a recent SSD is plenty fast.

  • Debugger attaches to a real PID

    Your IDE's "Attach to Process", lldb, perf, and Instruments all work because the service is just another OS process. No remote-debug protocol over a virtualised network, no fragile sidecar to keep alive.

  • Cold start in seconds, not minutes

    A fresh stack comes up as fast as the binaries can spawn because there is no VM boot or daemon warm-up. Restart your machine and your dev environment is back the moment you want it.

Activity Monitor · Energy
12 hr remaining
Battery94% · charging steady
ProcessCPUEnergyState
postgres0.0%0.1idle
redis0.0%0.0idle
mailpit0.1%0.1idle
stackied0.2%0.2idle

A full stack, idle

Energy impact stays in single digits, fans never spin up, lid close goes straight to sleep. The OS schedules your services like the native processes they are.

Build Your Own Stacks

Define your own stacks from our supported blocks, then run them with the native CLI or your existing Docker workflow.

stackie-stack.yml

Declare services, ports, and environment variables in a clean YAML file. Stackie handles native installation, sandboxing, and lifecycle.

my-app:
  blocks:
    postgres:
      vars:
        USER: admin
        DB: myapp
      environment:
        POSTGRES_PASSWORD: secret
      serves:
        PORT: 5432

Run it your way

Use the native Stackie CLI for full control, or keep your existing Docker commands, since Stackie's built-in Docker API makes both work identically.

$

Docker Compatible

Stackie includes a full built-in Docker Engine API, so your existing tools, scripts, and muscle memory work unchanged while retaining native performance underneath.

Your Docker context, native runtime

Create a stackie Docker context and your Docker workflow keeps working. Tools without context support can still use DOCKER_HOST. When you reference a supported image like postgres:15, Stackie maps it to the native block without a VM or image pull, which leaves just raw performance.

  • Same commands, native services

    docker compose up,docker ps, and docker logs keep your muscle memory intact. Stackie translates supported image references into native blocks running at bare-metal speed.

  • GUI tools just work

    Container panels in VS Code and JetBrains show your running services, ports, and logs. If it speaks Docker API, it works with Stackie.

  • Blocks, not containers

    Stackie maps supported image aliases to native blocks, so it doesn't pull images or build Dockerfiles. Postgres, Redis, MariaDB, and a growing list run as real processes, not emulated containers.

Works with

VS Code
JetBrains
Podman Desktop
Lazydocker
Containers
my-app
postgresRunning:5432
redisRunning:6379
apiRunning:3000
Resource UsageTotal: 22 MB
ProcessCPUMem
postgres0.0%15.2 MB
redis0.0%4.8 MB
api0.0%2.1 MB

Accelerated Agents

Stackie's built-in MCP server gives agents live access to your services, data stores, and the daemon itself, which turns every running stack into an autonomous development environment.

Your workflow, fully automated

Agents can read and operate your stack. Live service logs, database schemas, filesystem access, and daemon control are all exposed over MCP the moment your stack starts. No plugins, no glue code.

  • Deep stack integration

    Agents see your logs, schemas, migrations, and config, so they can use everything your stack knows. Diagnose a 500, apply a missing migration, and verify the fix in a single session.

  • Secure by design

    Stackie sandboxes every service, so agents can operate freely within their scope without risking cross-service interference. Full autonomy, strict boundaries.

  • Zero setup, instant access

    Stackie automatically enrolls itself with your local AI agent. Start a stack and your agent already has full MCP access without manual wiring or configuration steps.

Works with

Claude
Codex
Gemini
Cursor
OpenCode
agent session
agent>
Reading service logs via MCP
ERROR: column "avatar_url" does not exist on "profiles"
  POST /api/users/update → 500 Internal Server Error
Reading database schema via MCP
TABLE profiles
id          uuid
email       text
name        text← no avatar_url column
Scanning migrations via MCP filesystem
001_init.sql          applied
002_add_name.sql      applied
003_add_avatar_url.sqlpending ←
Migration 003 adds avatar_url but was never applied
Applying migration...
psql -d myapp < migrations/003_add_avatar_url.sql
Done. /api/users/update is returning 200

Stackie vs Docker Desktop

Purpose built for local development with cloud native stacks.

Feature
Stackie
Docker Desktop
RAM Usage
~15MB per service
2-4GB base + per service
Startup Time
Instant (native process)
5-15s (VM initialization)
CPU Performance
Native (no virtualization)
Virtualized (overhead)
Compose Support[1]
Partial (supported blocks)
Yes
Package Source[2]
Homebrew, npm, pip, and more
Docker Hub images
macOS Support
Native
Virtualized (VM)
Windows Support
Native
Virtualized (WSL2)
Linux Support
Native
Native
Admin/Root Required
No
Yes (optional on Linux)
Learning Curve
Low (simple YAML)
Medium (many concepts)
AI Agent Ready[5]
Built-in MCP server
Third-party integration required
Network Isolation[4]
Shared (like --network=host)
Multiple options
Filesystem Isolation
Platform-specific sandboxes
Containers
Best For[6]
Cloud Native, Local development
Kubernetes, Distributed containers

[1] Stackie ships a Docker Engine API compatibility layer in its daemon, so your existing Docker CLI, compose files, and tooling work natively with Stackie through a Stackie Docker context. DOCKER_HOST remains supported for tools that do not understand contexts. Only applies to services Stackie already supports.

[2] Stackie uses native package managers (Homebrew, npm, pip, etc.) instead of Docker images. Access your language's ecosystem directly.

[4] Stackie sandboxes share network space for simplicity. Good for local dev, different from Docker's approach.

[5] Stackie exposes daemon capabilities through its built-in MCP server; external agents do not require a separate Docker-side plugin.

[6] Stackie excels at cloud-native local development with minimal overhead. Docker is the industry standard for Kubernetes and distributed containerized deployments.

Bottom Line

Choose Stackie for:
  • Lightweight local development with minimal RAM overhead
  • Native performance without virtualization
  • AI-powered workflows with built-in MCP integration
  • Environments that restrict admin or root access
Choose Docker for:
  • Production container deployments and Kubernetes
  • Access to the full Docker Hub image ecosystem
  • Stacks that depend on Docker-specific features

Get Started in 3 Steps

From download to running your first sandbox in under 5 minutes.

1

Install

Run the one-liner for your platform. Installs to~/.stackie/bin/as a user-level install.

Full install instructions →
2

Create Stack

Create a stackie-stack.yml or use your existing docker-compose.yml.

my-app:
  blocks:
    postgres:
      vars:
        DB: "myapp"
        USER: "myapp"
        PASSWORD: "secret"
      ports:
        PORT: 5432
3

Run It

Use stackie up for native CLI or docker compose up via Stackie's built-in Docker API.

# Native Stackie
$ stackie up

# Docker compatible (built-in Docker API)
$ docker compose up

Need help? Check out the documentation or open an issue.

Requirements

  • macOS 11+, Ubuntu 20.04+, or Windows 10+ (64-bit)
  • ARM64 or x86_64 processor
  • User-level installer
  • Alpha software: Expect rough edges and bugs.

See It in Action

Stackie makes it quick and easy to run common stacks locally.

terminal
$

Frequently Asked Questions

Common questions about Stackie's features,compatibility, and use cases.

What makes Stackie different from Docker Desktop?

Stackie runs services as native processes on macOS, Windows, and Linux with minimal RAM overhead (~15MB vs 2-4GB+), uses native package managers instead of Docker images, and leverages platform-specific sandboxing for isolation. It's optimized for local development without the Linux VM overhead.

Can I use my existing docker-compose.yml files?

Yes, and your existing Docker workflows continue to work. See the Docker compatibility docs for setup instructions.

What operating systems does Stackie support?

Stackie supports macOS 11+ (Apple Silicon and Intel), Windows 10+ (64-bit), and Linux (Ubuntu 20.04+, Debian, Fedora, Arch, and others) on both ARM64 and x86_64 processors.

How does Stackie's sandboxing work?

Stackie uses platform-specific sandboxing to create isolated environments with explicit port and path whitelisting. See the Sandbox docs for a full breakdown of how isolation and permissions work.

Can Stackie access my system's Homebrew installation?

No, because Stackie uses its own isolated Homebrew installation to prevent conflicts with your system packages. See the installation docs for details on how Stackie manages its own tooling.

This template looks awfully familiar...

Good eye! This site is based on the excellent Astro landing page template by Markus Hsi-Yang Fritz and Peter Hijma. We customized it for Stackie's needs, but the clean design and performance optimizations are all thanks to their great work.