Developer overview

Campus is a software platform built around one premise: applications should have a durable place to run, a clear owner, and explicit authority.

The browser is not the computer. A Campus application can present an instant interface while its durable workload runs on a person’s own node or on Campus Compute. CampusOS coordinates identity, permissions, data, events, applications, and tools without turning application code into trusted platform code.

The installation is the principal.Every authority belongs to one account’s installation of one app. Package declarations describe the maximum an app may request; the stored installation grant is what it can actually do.

The platform model

Layer	System	Developer use
Platform service	CampusOS	Coordinate identity, permissions, data, events, apps, and tools.
Platform service	Campus Compute	Select execution resources and run durable, globally reachable software.
Platform service	Campus Intelligence	Access approved models through sealed credentials, budgets, and installation policy.
Platform service	Campus Payments	Move value and authorize exact financial intent.
Platform service	Campus Distribution	Package, publish, install, promote, roll back, and update software.
Developer system	CampusSDK	Connect browser, native, workload, and agent software to the platform.
Developer system	Campus UI	Build interfaces that behave like part of Campus.
Developer system	Campus Harness	Build persistent, tool-using agents and isolated workers.

One application model

A Campus app is a package with optional components:

Campus app
├── frontend          instant, content-addressed interface
├── workload          durable isolated execution
├── permissions       maximum requested authority
├── interfaces        MCP tools, public routes, sockets, events
├── agent             instructions, skills, context, worker roles
└── economic abilities  products, payments, paid services

These are composable components, not separate app types. A frontend-only utility, a public service, and a tool-using agent follow the same installation, grant, lifecycle, and distribution model. Read the unified application model for the complete contract.

The two paths through Campus

Control plane. CampusOS decides identity, grants, placement, lifecycle intent, billing admission, and public topology. Campus Mux carries control messages to a Node Runtime.

Application data plane. CampusSDK connects directly to the installation Gateway over Iroh. Gateway validates the installation capability before reaching the private workload. Public traffic enters through Campus Ingress and is independently checked again by Gateway.

Browser or native client → CampusSDK → Iroh → installation Gateway → workload
Public client            → Ingress   → Iroh → installation Gateway → workload
CampusOS                 → Mux       → Iroh → Node Runtime          → lifecycle

This separation keeps application traffic away from the control bridge and keeps backend addresses, reusable secrets, and other installations out of app code. Continue with architecture, authentication, and the permission model.

Where to start

1. Follow the quickstart to run the local vertical slice.
2. Read Build a Campus app to understand the package and runtime path.
3. Choose CampusSDK, Campus UI, or Campus Harness based on what you are building.
4. Use the reference index when you need exact API, permission, packaging, or protocol contracts.