Launching Gritiva — what we built and why

Last updated 4 min read
Report issue

Launching Gritiva#

Published 2026-05-14. Author: Mohammad, founder.

If this is the first time you're hearing about us, the Why GritivaCore page has the elevator pitch. This post is the story behind it.

Why we built it#

Every team I've worked with that runs more than two VMs but isn't ready for Kubernetes ends up with the same setup: a folder of bash scripts, an Ansible playbook that hasn't been touched in 18 months, hand-rolled WireGuard configs, and a Caddy file someone copied off Stack Overflow in 2022. It works. Sort of. Until someone needs to add a third VM, or the cert expires, or the laptop with the SSH keys gets reformatted.

The frustrating thing is — none of those teams want to manage infrastructure. They want to ship the thing they're actually building. The infrastructure is overhead. And the available options for "infra-but-not-Kubernetes" are either too thin (Tailscale + caddy + cron, hand-rolled glue) or too thick (full K8s with all the operational cost).

So we built Gritiva to fill that gap.

What's in v2.5 (today)#

  • A single-binary agent that brings each VM under management. One curl + sudo bash, 60 seconds, your VM is in the panel.
  • Scopes — netns + cgroup units of isolation. Lighter than VMs, more isolated than containers, no cluster required.
  • gmesh — WireGuard mesh between scopes across all your VMs. No central relay; full peer-to-peer.
  • DRM (Domain Routing Manager) — one CLI command to attach app.example.com to a scope on port 8080. Cloudflare DNS + cloudflared tunnel + nginx-in-scope + TLS cert, all reconciled.
  • A panel at panel.gritiva.com to see all of the above without ssh.
  • A docs site at docs.gritiva.com (this site!) — 56 docs covering operators, developers, end-users, sales, and legal.

What's not in v2.5#

  • Kubernetes compatibility. Different mental model; we don't translate.
  • Pod autoscaling. If you need HPA, you need K8s.
  • Multi-region failover. We have one region today (Hetzner Falkenstein).
  • A native Windows agent. Linux only on the host.
  • A native mobile app.

These are honest limitations, not coming-soon teases. If they're dealbreakers, Gritiva isn't the right tool today.

What we got right#

  • Source-available from day one. You can read every line of the agent, the docs system, the gmesh daemon. Audit it. Fork it. Run it offline.
  • Honest limits in the docs. The Why GritivaCore page tells you when not to use us. The vs Kubernetes page is brutally specific about the size where K8s wins.
  • A real postmortem culture — when our agent crashed in a loop on day 6, we wrote up the full story the same day. Public.
  • Real backend tree feeding the docs sidebar. No fake "Installation / Architecture / API" placeholder list — every doc on this site is an actual published doc.

What we got wrong#

  • The first batch of LLM-drafted concept docs all hallucinated generic Wikipedia content. We documented the failure mode — the LLM ignores the meta field — and worked around it with strong redraft notes. Real fix is on the roadmap.
  • A drift footgun on prod had us deploying the same fix three times in one afternoon before realizing prod was a Git working tree on a stale branch. Documented.
  • Sub-page admin panels are still bare-bones. The dashboard you see is fresh; the deeper pages haven't gotten the polish treatment yet.

We'll fix those things. We tell you about them anyway because that's how we work.

What's next#

Q3 2026 priorities:

  • API reference auto-generation from OpenAPI ✅ (just shipped)
  • Webhook delivery guarantees (at-least-once)
  • gmesh route reflectors to break the 50-peer ceiling
  • SOC2 Type I observation period

Q4 2026:

  • Self-hosted control plane GA
  • SAML / OIDC SSO
  • Audit log export

The full Roadmap is updated in real-time.

How to get involved#

Thanks for reading. We're excited to see what you build on top of it.

— Mohammad