612074af04
Turning CI on surfaced `atomic_write` as intermittently failing under load — self-inflicted. Its fault injection is `CREATE TRIGGER ... ON outbox`, which takes an ACCESS EXCLUSIVE lock on a table every other suite is concurrently inserting into. The header even claimed it "cannot affect any test running in parallel"; that was wrong — scoping the trigger by app_id bounds which ROWS it rejects, not the table lock installing it takes. Shipping that alongside "run the DB tests in CI" would have poisoned the signal. The fix is the one already used for the e2e suites: a private database per test. That logic (build a migrated template once, clone it per test via `CREATE DATABASE ... TEMPLATE`) was duplicated in `picloud/tests/common`, and this would have been a third copy — so it moves into a shared `picloud-test-support` dev-dependency crate, and `picloud/tests/common` now re-exports it. The invariant it encodes: manager-core's claim loops are global by design, so a test must not share a database with anything that runs them OR with anything that does DDL. Moved onto it: - `atomic_write` — the DDL fault injection above; its per-test cleanup is now deleted (the database is thrown away). - `outbox_reclaim` — asserts `reclaim_stale_claims` returns exactly 0, a count over the WHOLE outbox table. On the shared DB any stale row from any other suite (or a killed picloud that died holding a claim) would fail it permanently, until someone cleared the table by hand. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PiCloud
A lightweight, self-hosted, event-driven serverless compute platform. Upload a Rhai script, get an HTTP endpoint. Designed to run on a single modest server with no idle CPU cost, and to scale out to a small cluster when you need it.
Status: Phase 1 — MVP scaffolding in progress.
The authoritative design lives in
serverless_cloud_blueprint.md.
Why
Existing serverless platforms are either cloud-locked, heavyweight, or both. PiCloud aims for the opposite end of the spectrum: one binary, one database, one reverse proxy — running on hardware you already own.
Architecture (one paragraph)
PiCloud splits into three logical services — manager (control plane: scripts, schedules, dashboard), orchestrator (per-node event ingress and dispatch), and executor (per-node Rhai sandbox) — each backed by a *-core Rust library. In MVP they run in a single process; in cluster mode they run as three binaries with one manager and one orchestrator + executor per node. Caddy fronts everything; PostgreSQL is the single source of truth.
See CLAUDE.md for working notes and serverless_cloud_blueprint.md for the full design.
Quick Start
Coming as scaffolding lands. For now:
# Rust toolchain (pinned via rust-toolchain.toml)
cargo check --workspace
# Run the all-in-one MVP binary (once main.rs is wired up)
cargo run -p picloud
Repository Layout
crates/
shared/ cross-cutting types
executor-core/ Rhai engine + sandbox
orchestrator-core/ event ingress, dispatch
manager-core/ control plane
picloud/ MVP all-in-one binary
picloud-{manager,orchestrator,executor}/ cluster-mode binaries (skeleton)
dashboard/ SvelteKit
caddy/ Caddyfile
docker/ Dockerfiles
docs/
git-workflow.md Trunk-based workflow
Contributing
See docs/git-workflow.md for the branching and commit conventions. TL;DR: trunk-based, short-lived branches, Conventional Commits, no force-pushing main.
License
TBD.