DEV Community: Sharang Parnerkar

I Built a Container Orchestrator in Rust Because Kubernetes Was Too Much and Coolify Wasn't Enough

Sharang Parnerkar — Fri, 10 Apr 2026 09:21:30 +0000

There's a gap in the container orchestration world that nobody talks about.

Docker Compose works for 1 server. Coolify and Dokploy give you a nice GUI but still cap at one node. Kubernetes handles 10,000 nodes but requires a team of platform engineers just to keep the lights on.

What if you have 2 to 20 servers, 20 to 100 services, and a team of 1 to 5 engineers who'd rather ship features than debug etcd quorum failures?

That's exactly where I was. So I built Orca.

Docker Compose ──> Coolify/Dokploy ──> Orca ──> Kubernetes
   (1 node)         (1 node, GUI)      (2-20)     (20-10k)

TL;DR

Orca is a single-binary container + WebAssembly orchestrator written in Rust. One 47MB executable replaces your control plane, container agent, CLI, reverse proxy with auto-TLS, and terminal dashboard. Deploy with TOML configs that fit on one screen — no YAML empires, no Helm charts, no CRDs.

GitHub: github.com/mighty840/orca
Install: cargo install mallorca

The Problem

I was running ~60 services across 3 servers for multiple projects — compliance platforms, trading bots, YouTube automation pipelines, chat servers, AI gateways. Coolify worked great at first, but then I needed:

Services on multiple nodes with DNS-based routing per node
Auto-TLS without manually configuring Caddy/Traefik per domain
Git push deploys that actually work across nodes
Rolling updates that don't take down the whole stack
Config as code, not clicking through a GUI

Kubernetes was the obvious answer, but for 3 nodes and a solo developer? That's like buying a Boeing 747 to commute to work.

What Orca Actually Does

Single Binary, Everything Included

cargo install mallorca
orca install-service          # systemd unit with auto port binding
sudo systemctl start orca

That one binary runs:

Control plane with Raft consensus (openraft + redb — no etcd)
Container runtime via Docker/bollard
WebAssembly runtime via wasmtime (5ms cold start, ~2MB per instance)
Reverse proxy with Host/path routing, WebSocket proxying, rate limiting
ACME client for automatic Let's Encrypt certificates
Secrets store with AES-256 encryption at rest
Health checker with liveness/readiness probes and auto-restart
AI assistant that diagnoses cluster issues in natural language

TOML Config That Humans Can Read

[[service]]
name = "api"
image = "myorg/api:latest"
port = 8080
domain = "api.example.com"
health = "/healthz"

[service.env]
DATABASE_URL = "${secrets.DB_URL}"
REDIS_URL = "redis://cache:6379"

[service.resources]
memory = "512Mi"
cpu = 1.0

[service.liveness]
path = "/healthz"
interval_secs = 30
failure_threshold = 3

Compare that to the equivalent Kubernetes YAML. I'll wait.

Multi-Node in One Command

# On worker nodes:
orca install-service --leader 10.0.0.1:6880
sudo systemctl start orca-agent

The agent connects to the master via bidirectional WebSocket — no HTTP polling, no gRPC complexity. Deploy commands arrive instantly. When an agent reconnects after a network blip, the master sends the full desired state and the agent self-heals.

[service.placement]
node = "gpu-box"         # Pin to a specific node

GitOps Without a CI Runner

Orca has a built-in infra webhook. Point your git host at the orca API, and every push triggers git pull + full reconciliation:

# One-time setup:
curl -X POST http://localhost:6880/api/v1/webhooks \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"repo":"myorg/infra","service_name":"infra","branch":"main",
       "secret":"...","infra":true}'

Push a config change → orca pulls → deploys only what changed. No Jenkins, no GitHub Actions runner, no ArgoCD.

For image-only updates (CI pushes new :latest), register a per-service webhook and orca force-pulls + restarts.

How It Compares

Feature	Coolify	Dokploy	Orca	K8s
Multi-node	No	No	Yes (Raft)	Yes (etcd)
Config format	GUI	GUI	TOML	YAML
Auto-TLS	Yes	Yes	Yes (ACME)	cert-manager
Secrets	GUI	GUI	AES-256, `${secrets.X}`	etcd + RBAC
Rolling updates	Basic	Basic	Yes + canary	Yes
Health checks	Basic	Basic	Liveness + readiness	Yes
WebSocket proxy	Partial	Partial	Full	Ingress-dependent
Wasm support	No	No	Yes (wasmtime)	Krustlet (dead)
AI ops	No	No	Yes	No
GitOps webhook	Yes	Yes	Yes + infra webhook	ArgoCD/Flux
Self-update	No	Docker pull	`orca update`	Cluster upgrade
Lines of config per service	~0 (GUI)	~0 (GUI)	~10 TOML	~50-100 YAML
External dependencies	Docker, DB	Docker	Docker only	etcd, CoreDNS, ...
Binary size	Docker image	Docker image	47MB	N/A

The Smart Reconciler

One thing that drove me crazy with other orchestrators: redeploy a stack and everything restarts, even services that haven't changed.

Orca's reconciler compares the unresolved config templates (with ${secrets.X} intact), not the resolved values. If your OAuth token refreshed but your config didn't change, the container stays running. Only actual config changes trigger a rolling update.

orca deploy              # Reconcile all — skips unchanged services
orca deploy api          # Reconcile just one service
orca redeploy api        # Force pull image + restart (for :latest updates)

What's Coming in v0.3

The roadmap is driven by what we actually need in production:

Remote log streaming — orca logs <service> for containers on any node, piped via WebSocket
Preview environments — orca env create pr-123 spins up an ephemeral copy of a project
Per-project secrets — ${secrets.X} resolves project scope first, then global
TUI webhook manager — add/edit/delete webhooks from the terminal dashboard
TUI backup dashboard — per-node backup status, manual trigger, restore
ARM64 builds — native binaries for Raspberry Pi / Graviton
Log forwarding — ship container logs to Loki, SigNoz, or any OpenTelemetry collector
Nixpacks integration — auto-detect and build without Dockerfiles

Architecture for the Curious

┌─────────────────────────────────────┐
│         CLI / TUI / API             │
└──────────────┬──────────────────────┘
               │
┌──────────────▼──────────────────────┐
│         Control Plane               │
│  Raft consensus (openraft + redb)   │
│  Scheduler (bin-packing + GPU)      │
│  API server (axum)                  │
│  Health checker + AI monitor        │
└──────────────┬──────────────────────┘
               │ WebSocket
    ┌──────────┼──────────┐
    ▼          ▼          ▼
┌────────┐ ┌────────┐ ┌────────┐
│ Node 1 │ │ Node 2 │ │ Node 3 │
│ Docker │ │ Docker │ │ Docker │
│ Wasm   │ │ Wasm   │ │ Wasm   │
│ Proxy  │ │ Proxy  │ │ Proxy  │
└────────┘ └────────┘ └────────┘

8 Rust crates, ~15k lines, 120+ tests. Every source file under 250 lines. The dependency flow is strict: core <- agent <- control <- cli. No circular deps, no god modules.

Want to Contribute?

Orca is open source (AGPL-3.0) and actively looking for contributors. The codebase is designed to be approachable:

Small files — 250 line max, split into clear submodules
Comprehensive tests — 120+ unit and integration tests
Architecture guide — CLAUDE.md documents every crate, convention, and design decision
Real issues — every open issue comes from production usage, not hypotheticals

Good first issues:

ARM64 CI build — add a GitHub Actions matrix for aarch64
TUI log viewer — stream container logs in a ratatui pane
Backup --exclude — skip specific volumes from nightly backup
Service templates — WordPress, Supabase, n8n one-click configs

git clone https://github.com/mighty840/orca.git
cd orca
cargo test        # 120+ tests
cargo build       # single binary

Links

GitHub: github.com/mighty840/orca
Docs: mighty840.github.io/orca
crates.io: crates.io/crates/mallorca
Changelog: CHANGELOG.md

Orca is built by developers running real production workloads on it — trading bots, compliance platforms, YouTube automation, AI gateways. Every feature exists because we needed it, every bug fix comes from a real 3 AM incident. If you're stuck between Coolify and Kubernetes, give it a shot.

Star the repo if this resonates. Open an issue if something's broken. PRs welcome.

Design decisions behind KitchenAsty — an open-source restaurant management system

Sharang Parnerkar — Wed, 25 Feb 2026 10:24:55 +0000

In my previous post, I introduced KitchenAsty — an open-source, self-hosted restaurant ordering and management platform. People asked about the architecture, so this post dives into the core design decisions: how the real-time system works, how the database handles guest orders and price changes, how settings resolve from multiple sources, and how a data-driven automation pipeline lets restaurant owners set up custom workflows without writing code.

1. Real-Time Architecture: Rooms, Not Broadcasts

A restaurant system has two audiences that need live updates simultaneously: kitchen staff watching for incoming orders, and customers tracking their delivery. Broadcasting everything to everyone would be wasteful and insecure.

Socket.IO's room abstraction solves this cleanly. There are two room types:

kitchen — a single shared room. Every kitchen display client joins it. When a new order arrives or any order changes status, the event goes here.
order:{orderId} — one room per active order. The customer's browser or mobile app joins their specific order room. They only receive updates about their order.

// Client joins on mount
socket.emit('join:kitchen');     // kitchen display
socket.emit('join:order', id);   // customer order tracking

// Server emits to both rooms on status change
io.to('kitchen').emit('order:statusUpdate', order);
io.to(`order:${order.id}`).emit('order:statusUpdate', order);

This means 50 customers tracking 50 orders generate 50 targeted messages, not 50 broadcasts. The kitchen display gets every update because it's in the shared room.

On the kitchen display itself, updates are applied optimistically — the UI updates immediately on button click, and the Socket.IO event from the server reconciles in the background. If the status moves the order off the Kanban board (e.g., "delivered"), the socket handler removes it from local state:

s.on('order:statusUpdate', (data) => {
  setOrders((prev) => {
    if (!KITCHEN_STATUSES.includes(data.status)) {
      return prev.filter((o) => o.id !== data.id);  // gone from board
    }
    return prev.map((o) => o.id === data.id ? { ...o, status: data.status } : o);
  });
});

2. Database: Snapshots, Not References

The most important database design decision was this: order items store a snapshot of the menu data at the time of purchase, not just a foreign key.

model OrderItem {
  menuItemId String
  menuItem   MenuItem @relation(...)
  name       String      // "Margherita Pizza" — frozen at order time
  unitPrice  Float       // 12.99 — frozen at order time
  subtotal   Float
}

model OrderItemOption {
  name          String   // "Extra Cheese" — frozen
  value         String   // "Yes" — frozen
  priceModifier Float    // 2.50 — frozen
}

The foreign key to MenuItem is still there for analytics (which menu items generate the most revenue), but the name, unitPrice, and priceModifier fields are what the order actually uses. If the restaurant changes the price of a pizza next week, existing order records aren't affected.

This matters more than you'd think. Restaurants update prices frequently — seasonal menus, promotions, cost adjustments. Without snapshots, your revenue reports lie and customer receipts change retroactively.

Guest checkout with optional customer

Orders support both registered customers and guests through an optional relationship:

model Order {
  customerId String?     // null for guest orders
  customer   Customer?
  guestName  String?     // fallback fields for guests
  guestEmail String?
  guestPhone String?
}

The auth middleware on the order creation endpoint uses optionalAuth — it attaches the user if a token is present but doesn't block the request otherwise. The controller checks: if there's a logged-in customer, link the order; if not, store the guest fields.

Self-referential categories

Menus need nested categories (e.g., "Drinks" > "Hot Drinks" > "Coffees"). Rather than a flat list with a separate hierarchy table, the schema uses a self-referential adjacency list:

model Category {
  parentId String?
  parent   Category?  @relation("CategoryTree", fields: [parentId], references: [id])
  children Category[] @relation("CategoryTree")
}

One query with include: { children: true } gives you the full tree. Simple to query, simple to render, and Prisma's type system ensures you can't accidentally create orphans.

3. Settings: DB-First with Env Var Fallback

Restaurant owners configure their system through the admin panel (stored in the database). Developers configure it through environment variables during deployment. Both need to work, and the admin panel should win when both are set.

The pattern looks like this for email configuration:

async function getMailConfig() {
  // Start with env var defaults
  let host = process.env.SMTP_HOST || 'localhost';
  let port = parseInt(process.env.SMTP_PORT || '1025');

  try {
    // DB settings override env vars
    const settings = await prisma.siteSettings.findUnique({
      where: { id: 'default' }
    });
    const mail = settings?.mailSettings || {};
    if (mail.smtpHost) host = mail.smtpHost;
    if (mail.smtpPort) port = mail.smtpPort;
    // ...
  } catch {
    // DB unavailable — env vars are the fallback
  }
}

The entire site configuration lives in a single database row — SiteSettings with id: 'default'. JSON columns hold grouped settings (general, orders, mail, payments, reservations, reviews, advanced). This avoids a key-value settings table and keeps related settings together.

Two details that took some thought:

Caching — The mail transporter is cached for 5 minutes to avoid a database round-trip on every email. When settings are updated through the admin API, invalidateMailCache() forces a rebuild on the next send.

Secret masking — API keys and passwords are masked in API responses (sk_l...4x8f). When the admin submits the settings form, if a field still looks masked, the server preserves the existing database value instead of overwriting it with the mask string:

function preserveIfMasked(newVal, existingVal) {
  if (isMasked(newVal)) return existingVal;
  return newVal;
}

This means the frontend never holds real secrets in memory — it only ever sees masked values.

4. Auth: Composable Middleware, Two User Types

Staff and customers share the same JWT structure but are treated as distinct principals:

interface JwtPayload {
  id: string;
  email: string;
  type: 'staff' | 'customer';
  role?: 'SUPER_ADMIN' | 'MANAGER' | 'STAFF';
}

Access control is built from three composable middleware functions:

authenticate        // require any valid JWT
requireStaff        // require type === 'staff'
requireRole(...roles)  // require specific role(s)

These compose at the route level:

router.post('/',            optionalAuth, createOrder);       // guests OK
router.get('/my-orders',    authenticate, listCustomerOrders);
router.get('/',             authenticate, requireStaff, listOrders);
router.patch('/:id/status', authenticate, requireStaff, updateOrderStatus);

The optionalAuth variant is key for guest checkout — it attaches the user if present but doesn't reject anonymous requests.

Staff invitation uses single-use tokens with a 7-day expiry stored in the database. When a new staff member accepts an invitation, the token is marked as used to prevent replay.

5. Automation: Data-Driven Event Pipeline

This was the most interesting piece to build. Restaurant owners need custom workflows — "email the customer when their order is confirmed", "send an SMS when the order is ready for pickup", "notify the manager via webhook when a bad review comes in" — without touching code.

The pipeline has three layers:

Layer 1 — EventEmitter as internal bus. Controllers emit domain events after mutations:

// After creating an order
appEvents.emit('order.created', { order });

// After changing order status
appEvents.emit('order.statusChanged', { order, previousStatus });

Layer 2 — DB-driven rule matching. When an event fires, the system queries for active automation rules that match:

async function processRules(event, data) {
  const rules = await prisma.automationRule.findMany({
    where: { event, isActive: true },
  });
  for (const rule of rules) {
    if (matchesConditions(rule.conditions, data)) {
      for (const action of rule.actions) {
        executeAction(action, data);
      }
    }
  }
}

Conditions support dot-notation paths, so a rule can match on order.status === 'CONFIRMED' or order.type === 'DELIVERY'.

Layer 3 — Action execution. Three action types: email, sms, and webhook. Templates use {{dot.path}} interpolation:

{
  "type": "email",
  "to": "customer",
  "subject": "Your order #{{order.orderNumber}} is confirmed!",
  "body": "Hi {{order.customer.name}}, we're preparing your order."
}

The "to": "customer" field resolves dynamically — it walks data.order.customer.email, then falls back to data.order.guestEmail. This works transparently for both registered and guest orders.

Everything is stored as JSON in the AutomationRule model, so restaurant owners create and manage rules through the admin panel without deployments.

6. Shared Types: Thin by Design

The packages/shared package is intentionally minimal — it exports as const arrays that serve as both runtime values and TypeScript types:

export const ORDER_STATUSES = [
  'pending', 'confirmed', 'preparing', 'ready',
  'out_for_delivery', 'delivered', 'picked_up', 'cancelled',
] as const;

export type OrderStatus = (typeof ORDER_STATUSES)[number];

The package does not re-export Prisma types. The admin and storefront apps import from @kitchenasty/shared without taking a transitive dependency on Prisma or any server-side code. This keeps frontend bundles clean and avoids the common monorepo trap where everything depends on everything.

Shared response shapes (ApiResponse<T>, PaginatedResponse<T>) ensure the API contract is consistent across all endpoints without a code generation step.

What I'd Do Differently

A few things I'd reconsider if starting over:

tRPC instead of REST — type-safe API calls without hand-written fetch wrappers. The shared types package partially solves this, but tRPC would eliminate the gap entirely.
Structured logger from day one — the codebase currently uses raw console.* calls. Adding pino or winston after the fact means touching every file that logs. This is an open issue if you want to help.
Component tests for the frontends — the backend has 330+ tests but the React apps have zero unit tests. Integration coverage through Playwright helps, but component-level tests would catch more regressions.

Try It / Contribute

Live demo: demo.kitchenasty.com (resets every 2 hours)
GitHub: github.com/mighty840/kitchenasty
Docs: kitchenasty.com

If any of these patterns are interesting to you, there are good first issues and help wanted issues covering accessibility, i18n, test coverage, and more. Happy to answer questions in the comments or in GitHub Discussions.

I built an open-source alternative to Toast and Square for restaurant management

Sharang Parnerkar — Mon, 23 Feb 2026 21:47:49 +0000

The Problem

If you run a small restaurant, your options for online ordering and management are:

SaaS platforms like Toast, Square, or ChowNow — $100-300+/month with vendor lock-in
Old open-source projects — mostly PHP/Laravel, hard to extend, dated UIs
Build it yourself — months of work before you can take a single order

I wanted a fourth option: a modern, self-hosted, open-source platform that a developer could deploy in an afternoon.

Introducing KitchenAsty

KitchenAsty is an MIT-licensed restaurant ordering, reservation, and management system built as a TypeScript monorepo.

What it covers

For customers:

Browse the menu, add to cart, and place orders for delivery or pickup
Schedule orders for later or order ASAP
Pay with Stripe or cash on delivery
Track orders in real-time
Book table reservations
Leave reviews
React Native mobile app

For restaurant staff:

Manage menus with categories, options, allergens, and images
Kitchen display — a live Kanban board showing incoming orders
Process orders with one-click status progression
Manage reservations with table assignment
Create and track coupons
Moderate customer reviews
Staff management with role-based access

For the owner:

Dashboard with revenue trends, order analytics, and top-selling items
Multi-language support (6 languages)
Full settings panel for payments, email, orders, and more

Tech Stack

Layer	Tech
API	Node.js + Express
Admin & Storefront	React 18 + Vite
Mobile	React Native + Expo
Database	PostgreSQL + Prisma
Real-time	Socket.IO
Payments	Stripe
Styling	Tailwind CSS
Testing	Vitest + Playwright (330+ tests)
Language	TypeScript (strict mode everywhere)

Architecture Decisions

A few choices I made and why:

Monorepo with npm workspaces — Admin, storefront, server, and shared types all live in one repo. Changes to shared types are immediately visible everywhere. No publishing packages, no version mismatches.

Prisma over raw SQL — Type-safe database queries that catch errors at build time. The schema is self-documenting with 30 models and clear relationships.

Socket.IO for real-time — The kitchen display and order tracking need instant updates. Socket.IO made this straightforward with room-based broadcasting.

Separate admin and storefront apps — Different audiences, different concerns. The admin is a dense data-management tool. The storefront is a consumer-facing ordering experience. Sharing a single React app would have meant too many compromises.

Self-Hosting

The project is designed to be self-hosted with Docker. The docs site has a complete guide covering:

Server setup (Ubuntu/Debian)
Docker Compose deployment
Domain and DNS configuration
Reverse proxy with SSL (Nginx or Caddy)
Backups and maintenance

For local development, it's docker compose up -d for PostgreSQL, then npm run dev:server / npm run dev:admin / npm run dev:storefront.

By the Numbers

27,000 lines of TypeScript
30 database models
118 API endpoints
330+ tests (unit, integration, E2E)
6 supported languages
Full CI/CD with GitHub Actions

Contributing

The project is set up for contributors:

Contributing guide
Good first issues — small, well-scoped tasks with clear instructions
Help wanted issues — bigger features where input is welcome
Discussions — feature ideas, RFCs, and community chat

Areas where help is most needed: accessibility, i18n coverage, test coverage, and structured logging.