University Peer Cloud
A campus-owned teaching cloud that turns opted-in student and lab computers into a governed hosting pool. The college controls identity, policy, and scheduling while isolated application workloads run only on contributed capacity.
- Origin
- Original project
- Role
- Product, design & technology
- Focus
- platform
- Engineering Area
- Web
- Domain
- Developer & education
- Status
- Ideation
Full project notes
Product and engineering deep dive
The project overview adds a concise presentation layer. The complete product details remain below.
From intent to implementation
A product direction shaped around a real use case.
A campus-owned cloud platform where a college control plane securely schedules student projects across opt-in student computers, turning spare compute into a shared application-hosting pool without running workloads on the administration server.
What people can do with it
- Self-service project deployment for every student through a campus developer portal
- Opt-in node agent that lends bounded CPU, memory, storage, and network capacity
- College-hosted control plane for scheduling, health checks, quotas, service discovery, and policy
- Container isolation so hosted applications cannot access the student’s files or local network
- Heartbeat-based failover and replica placement across independently available student computers
- Campus ingress, TLS, and application URLs routed only to healthy student-hosted replicas
- Usage credits and contribution points based on verified uptime and requests served
- Stateless-first hosting with replicated storage introduced only for workloads that need persistence
System architecture
College-governed. Student-powered.
The administration server remains the trusted control plane; application workloads execute only on opted-in student computers.
College control plane
API gateway, identity, deployment registry, scheduler, quota manager, health monitor, policy engine, and audit log. It orchestrates workloads but does not execute student applications.
Student node agent
An opt-in background service advertises available resources, enforces lending limits, sends signed heartbeats, pulls approved images, and manages the local container sandbox.
Secure campus network
WireGuard-based overlay networking gives every node and workload a private identity without exposing student devices directly to the internet.
Workload runtime
Containerd or Docker runs resource-limited containers; k3s provides scheduling primitives, replica placement, service discovery, and controlled restarts.
Ingress and routing
Traefik terminates TLS at the college edge and forwards requests only to healthy replicas discovered through the control plane.
Observability and accounting
OpenTelemetry, Prometheus, and Grafana track health, latency, resource consumption, uptime, and contribution credits.
Skills required
Engineering depth needed to make it trustworthy.
Distributed systems
Heartbeats, failure detection, leader election, eventual consistency, replication, idempotency, and capacity-aware scheduling.
Containers and Linux
Namespaces, cgroups, image lifecycle, process isolation, resource limits, and secure container execution.
Networking
Overlay networks, DNS, service discovery, reverse proxies, TLS, NAT traversal, and load balancing.
Cloud security
Zero-trust node identity, signed workloads, secrets management, least privilege, policy enforcement, and tenant isolation.
Platform engineering
Developer portals, deployment APIs, workload manifests, quotas, rollouts, logs, and self-service workflows.
SRE and operations
SLOs, monitoring, alerting, incident response, graceful degradation, capacity planning, and abuse controls.
Delivery approach
Start stateless. Earn reliability.
- 01
MVP: host stateless HTTP applications on lab and student computers with explicit opt-in and fixed resource limits.
- 02
Reliability: add multiple replicas, health-based rescheduling, rolling deployments, logs, metrics, and campus-wide ingress.
- 03
Trust: add signed images, SPIFFE identities, OPA policies, vulnerability scanning, secret delivery, and per-project network rules.
- 04
Stateful workloads: introduce replicated volumes only after the stateless platform is reliable and operationally understood.
Architecture realities
What makes the idea difficult—and worth designing carefully.
- Student computers are intermittent, heterogeneous, and frequently behind restrictive networks.
- The platform must never use resources beyond the owner’s explicit limits or interfere with normal device use.
- Untrusted student code requires strong isolation, image scanning, egress controls, and rapid revocation.
- Reliable state is significantly harder than stateless compute and should not be part of the first release.
- College policy, consent, acceptable-use rules, privacy, and academic-integrity controls are product requirements—not paperwork after launch.
Project sponsorship
Fund this project—from prototype to production.
Help move University Peer Cloud from a promising prototype to a reliable production release.
- Design validation and user research
- Production infrastructure and security
- Testing, accessibility, and launch readiness
Secure checkout by Razorpay. Sponsorship does not provide equity, ownership, or a guaranteed delivery date.
REQUEST A DEMO
Want to see University Peer Cloud in context?
Share what you would like to explore.
Conversation
What did this make you think about?
Sign in to like or comment.