Skip to content
PatternYard Architecture

What is PatternYard

PatternYard is a self-hosted block-coding platform — an independent instance of the PenguinMod/Scratch lineage, running entirely on our own infrastructure under patternyard.dev. It is not one app; it is a small constellation of deployed services plus a larger set of supporting libraries.

These docs are the source of truth for how it all fits together: which project owns what, how requests flow between the editor, the home site, and the backend, and how to change things safely.

The system at a glance

Section titled “The system at a glance”

The platform splits into three deployed user-facing surfaces (home, editor, packager), one backend API, two content services, and a docs site. Everything is wired together through environment variables — there are no hardcoded cross-service URLs left.

Diagram

The three boundaries that matter

Section titled “The three boundaries that matter”

  1. Editor vs. Home are separate origins. The editor (studio.) and the home site (apex) are different deployments on different subdomains. This is why credentialed calls need CORS allowlisting and why the editor reads login state through a cross-origin /embed/editor bridge rather than sharing a session directly.

  2. The backend is the only thing that touches storage. The editor, home, and packager never talk to the database or Blob directly — they go through the api. backend. Storage credentials live only on the backend project.

  3. Content roots are swappable. The editor resolves five content roots (PM_API_ROOT, PM_EXTENSIONS_ROOT, PM_DOCS_ROOT, PM_LIBRARY_ROOT, PM_ASSET_CDN_ROOT) at build time. They point at our subdomains now, but the code defaults stay upstream so the fork remains mergeable.

Where to go next

Section titled “Where to go next”