zerra

An Extension-Based Runtime for Self-Hosted Digital Workspaces.

Comment

About the Project

Inspiration

Every single school day, I log into multiple different apps just to get basic work done. Assignments live in one place. Announcements live somewhere else. Messaging is separate. Attendance is separate. None of it talks to each other.

At the same time, as a young developer, I run into a different version of the same problem. Most tools today are SaaS-first. They assume you’ll subscribe, not build. If I want to create something new, I either have to stitch together external services or rebuild infrastructure from scratch.

That friction inspired zerra.

What if organizations — even schools — could own their runtime? What if features weren’t giant monolithic apps, but isolated extensions? What if SaaS became optional instead of mandatory?

zerra is my answer to that.

What zerra Is

zerra is an extension-based, self-hosted workspace runtime.

Instead of building one massive application, zerra runs a server where:

  • Every feature is an extension
  • Extensions are isolated
  • Services enforce permissions
  • Users and roles are global
  • The core remains domain-agnostic

The idea is simple:

The core should not “know” about attendance, messaging, or announcements.

Those are extensions.

This keeps the system modular, deterministic, and extensible.

On top of zerra, I built a school workspace using:

  • Announcements
  • Attendance tracking
  • Messaging
  • Calendar
  • Role-based access control

Each of those is a separate extension running on the same runtime.

zerra vs zerra labs

It’s important to distinguish the software from the business.

zerra is the open-source runtime. It is self-hosted. It is extension-based. It is owned by the organization.

zerra labs is a separate company that builds proprietary connection extensions.

zerra labs creates managed integrations — for example:

  • Email gateways
  • Payment processors
  • Cloud services
  • External APIs

The key idea is separation:

The core runtime remains owned and open. Commercial integrations are optional extensions.

This model reduces vendor lock-in while still enabling a sustainable business.

How I Built It

The server is built using Deno. Extensions run in isolated workers. Each service exports a request handler that processes structured requests and enforces permissions.

The client is built using SvelteKit and Tauri. Panels are static bundles that communicate with services through a structured request interface.

The system includes:

  • Global users
  • Role-based permissions
  • Extension metadata
  • Dynamic extension loading
  • Isolated service instances

Permission enforcement happens at the service layer. Panels never assume access — the service validates every request against the user’s roles.

For example, if a user tries to mark attendance, the service checks whether they have the attendance.mark permission before processing the request.

This keeps authorization centralized and consistent without coupling extensions to the core.

What I Learned

This project taught me:

  • How to design protocol-first systems instead of feature-first systems
  • The importance of isolation and modular architecture
  • How to separate infrastructure from business logic
  • How to think about permissions and roles as first-class primitives

I also learned that architectural clarity matters more than feature count. A clean, extensible system scales better than a large, tightly coupled one.

Challenges I Faced

1. Avoiding Core Contamination

One of the hardest challenges was resisting the urge to hard-code school logic into the core server. It’s easy to just “quickly add” a feature directly. But that breaks the philosophy.

Keeping the core generic required discipline.

2. Designing a Permission System

I had to implement a roles and permissions model that:

  • Remains generic
  • Does not understand domain concepts
  • Still enforces strict access control

The core only understands permission strings. Extensions decide which permissions they require. This separation was tricky but important.

3. Balancing Scope

With limited time, it would have been easy to overbuild.

Instead of trying to recreate a full student information system, I focused on:

  • A clean runtime
  • A few composable extensions
  • A working demo

That discipline helped me ship something coherent.

Why This Matters

Most tools today assume centralized control.

zerra flips that assumption.

The organization owns the runtime. Features are modular. SaaS is optional.

This project is not just a school app — it’s infrastructure for building digital workspaces without lock-in.

And this is just the beginning.

Built With

Share this project:

Updates