Home/The Stack
Under the hood

The whole machine —
and every license that
makes it yours.

No black boxes, no proprietary lock-in you can't see. This is the complete deployable system, component by component, with the licensing posture that lets us ship it on your hardware and charge for access — while leaving the parts you forked free of upstream constraint.

The shape of it

The architecture is fixed. The components move — and the harness moves you with them.

Model names, tooling, and hardware below are point-in-time as of our current research and will change. The architecture does not. The product does not bet on one model; it bets on the harness's ability to run the right current one, and to move when the frontier moves.

That single property — model-layer abstraction — is what turns "the model got deprecated" from a crisis into a maintenance ticket.

The part they'd rather you not notice

The capability is no longer rare. Open-weight AI running on hardware you control is now a commodity. What you're actually paying a platform for is convenience and lock-in. The magic already left the building — what stayed behind is the meter.

The platform, component by component

Eight layers, one deployable system.

Hardened base

The floor

A security-baselined Ubuntu build: minimal attack surface, locked-down defaults, automatic security patching, and full-disk and at-rest encryption options. Delivered as deployment scripts that take bare hardware or a bare VM to a hardened, ready host with one command — or a guided BYO-hardware run. The first thing the maintenance relationship keeps current.

The harness

Core IP · most defensible asset

The orchestration and control layer. It runs and routes to the model layer, manages agents and multi-step workflows, exposes tools to those agents, handles memory and context, and presents a usable interface — chat, API, and management. Crucially, it abstracts the model layer so you are never bound to a single model. This abstraction is what makes model migration a service the maintenance relationship can deliver.

The model layer

Open-weight, served locally

Open-weight models served locally through a standard runtime — Ollama for straightforward single-node deployments, a higher-throughput server like vLLM for heavier multi-node use. The harness selects and routes among models by task. Commercially-clean choices today: Qwen 3.5/3.6 and Gemma 4 (Apache 2.0), the Phi-4 family (MIT), DeepSeek V4 and larger Qwen variants for coding and reasoning, and Mistral families for EU-sensitive or low-latency single-GPU use.

Deployment tooling

Bare metal → running stack

Ansible playbooks and container tooling — Podman as the system-wide default, Docker where required — that provision the hardened base, install the runtime and harness, load the model and template layers, and verify the result. The same tooling underpins founder-delivered deployment today and self-serve onboarding later.

Template & skill library

Useful on day one

The maintained collection that makes the stack useful immediately: agent configurations, tool integrations, workflow templates, and task-specific skills. Its worth is entirely a function of how current it is — which is why it's a continuously updated paid layer, not a one-time deliverable.

Integration layer

MCP & connectors

MCP and connector support that lets the stack reach your own data and tools — files, databases, internal services, messaging, third-party APIs — so the owned stack does real work against real systems rather than running in isolation.

BYO-hardware path & fungible compute

Keeps ownership real

The documented, supported route to run the entire system on hardware you already own or buy once — a workstation with a capable GPU, a Mac with sufficient unified memory, or a small server. Compute providers are fungible by design: your hardware, commodity bare-metal arranged through the co-op, or a mix, swappable so no member is locked to a provider.

Observability, security & updates

The recurring relationship, embodied

Monitoring, logging, health checks, and the update channel through which the maintenance relationship delivers security patches, model migrations, and template refreshes. This mechanism is the technical embodiment of the license and the recurring relationship.

The one principle everything rests on

"Is it forkable" is the wrong question. This is the right one.

Nearly every license — open-source and source-available alike — permits forking. The filter that actually matters: can it be forked, modified heavily, kept proprietary, shipped inside the paid platform, and run free of upstream constraint? That property is precisely the permissive green tier — MIT, Apache 2.0, BSD, ISC. Apache 2.0 edges out MIT for this stack because of its explicit patent grant, which matters in ML tooling.

The traps look identical to permissive software on GitHub. "Fair-code," "source-available," and "sustainable" are the marketing words that signal a use restriction designed to stop exactly the business we're in.

LicenseFork & keep proprietary?Ship commercially?Fit
MIT · BSD · ISC · CC0Yes, fullyYesGreen — default
Apache 2.0Yes, fully (+ patent grant)YesGreen — best for ML
MPL 2.0Partial — changed files publishYesYellow — workable
LGPL 2.1 / 3Yes, as a relinkable libraryYesYellow — with discipline
GPL v2 / v3No, if combined into one workYes, but open the whole workSeparate process only
AGPL v3No — adds a network-use triggerYes, with the network obligationUnmodified service only
SUL · SSPL · BSL · Elastic v2Restriction rides every copyRestricted or forbiddenAvoid / license

Keeping every copyleft component as a separate process sidesteps the entire compatibility question — aggregated programs that merely talk at runtime are never "combined into one work," so their licenses never have to be reconciled.

The stack inventory

Every component, every license, sorted by what it lets us do.

ComponentRoleLicenseTier
Podman / Buildah / SkopeoContainer runtime · defaultApache 2.0Green
OllamaSingle-node model servingMITGreen
vLLMHigh-throughput servingApache 2.0Green
llama.cppInference / quantization (GGUF)MITGreen
Node-REDWorkflow automation (n8n substitute)Apache 2.0Green
Ansible (ansible-core)Deployment toolingGPLv3Green in practice
Ubuntu (hardened base)Host OSAggregate (GPL/LGPL + many)Yellow if reshipped
Open WebUI (≥ 0.6.6)Chat / management UIBSD-3 + branding clauseRed for white-label
n8nWorkflow automationSustainable Use LicenseForbids the model
Qwen 3.5 / 3.6General / agentic modelApache 2.0Green
Gemma 4Edge / multimodal modelApache 2.0 (v4 only)Green
Phi-4Constrained-hardware modelMITGreen
DeepSeek V4Coding / reasoning modelMITGreen
Llama 4ModelLlama 4 Community LicensePull + EU gate
The harness, control plane, premium templatesProprietary IPOutbound EULAIP company owns
Two things we're careful about

Model weights are a separate category

A model license is not a code license, and the same family can flip licenses between releases in either direction. Two operational rules govern everything: version-specificity is decisive (re-check on every upgrade), and pull, don't redistribute — the deployment tooling fetches weights at deploy time from your chosen source, so the weights are never "in" the shipped artifact.

§

The outbound license is honest about itself

"Modify freely, do not resell" is a coherent proprietary EULA — and it is not open source, and we never call it that. It binds only our own proprietary work; bundled MIT/Apache components reach you under their own terms and stay redistributable as those parts. The label simply matches the substance.

The divergence tax — our own thesis, turned inward. Our core insight is that forking the open core transfers the full maintenance burden onto whoever forks. That applies to us, too: every heavy fork of an upstream tool means owning its merges, security backports, and compatibility fixes forever. So the default for most of the stack is not fork — consume upstream as an unmodified, version-pinned dependency and contribute fixes back. We fork to control direction; we depend-and-pin to merely use.

Questions, answered

The objections worth taking seriously.

Q1What if I just fork the open source and do it myself?+
You can — the core is genuinely open, and the exit is always available. But you then inherit the full maintenance burden: model migration as the frontier moves, security hardening, template upkeep. That ongoing work is precisely what membership carries for you. The fork is legal, and self-defeating by design.
Q2Do I need to buy expensive hardware?+
No. Run it on hardware you already own, on a private VPS, or on commodity compute the co-op arranges — or any mix. Compute is fungible by design, so you're never locked to a provider. The point isn't where it runs; it's that you control where it runs.
Q3Which AI models does it run?+
Open-weight models with clean commercial licenses — the Apache 2.0 and MIT families (Qwen, Gemma, Phi, DeepSeek and peers). The harness abstracts the model layer, so you're never bound to one: when a better open model ships, the stack adopts it without you re-architecting.

Want this running on your hardware?

A fixed-scope deployment assesses your workloads, hardens the host, integrates your data and tools, and hands over with documentation and training — membership and maintenance attached.

Request an invitation →

A stack you can read,
fork, and keep.

Request an invitation to the founding cohort. We'll scope the deployment against your real workloads and hardware.