CARLOS
Why your organisation would run on CARLOS, and what you get when you do.
For adopters · draft 1 · September 2026 · carlosframework.com
Adopter edition of the deck. No funding content. The motif is the same owned instance: one binary and one file inside a boundary that is yours.
where you are
Per seat, per month, forever. Your data in someone else's tables. Their outage, their roadmap, their price rise.
The problem from the buyer's side. Spoken: every one of these was a fair trade fifteen years ago, because owning meant servers, patching and uptime. The next slides are what changed.
Aimed at vendor excess: enterprise features nobody asked for, AI badges on everything, a trust centre instead of a database you can inspect. Not at the legitimate reasons your team chose SaaS. Say it, pause, move on.
the answer
One app binary and one database file, with updates and operation still managed.
The value proposition. Mechanics (Go, SQLite, channels, hibernation, residency) are in the appendix.
what you get
Each app is one instance per team, open, and yours to run wherever you like.
Team chat. Replaces Slack, Teams.
Email and sign-on. Replaces Gmail, Outlook, Okta.
Docs, sheets, calendar, files. Replaces Google Workspace, Microsoft 365.
Code hosting and CI. Replaces GitHub, GitLab.
Social. Replaces the feed you do not control.
Mailing lists. Replaces Mailchimp. shipping this week
Shipped or shipping apps only. Ocho (personal messaging) and Dineraya (payments) are in development and sit in the appendix catalogue with their status. Trust posture per app is also in the appendix: Eleven, Keymail, Woodstar and amadan are end-to-end encrypted; Oficina is sealed per team; Correomona is server-side with named leaks tested.
secure
That is the test every CARLOS app is held to. For most of the suite, the answer is nothing.
Isolation is the operating system's boundary, not a WHERE clause; there is no team_id column. E2EE apps leave no plaintext in storage, proven by canary tests. Apps that must read data (mailing lists) list every plaintext column and a CI test fails when a new one appears. What the test does not prove (key handling, live-host compromise) is in the appendix.
fast
One binary, one file next to it, server-rendered pages. No client framework to download before you see a word.
Wake time is what the family's apps see day to day, not a published benchmark; say so if asked. Memory 20 to 60 MB per running tenant. Details in the appendix.
cost
A parked app runs no process. Its data waits in storage until the next request wakes it.
Carloku is one provider; self-hosters pay for their own hardware and storage only. Illustrative operating cost with its assumptions on the slide.
where it runs
Hosting is a choice made outside the instance's boundary.
Same hostname, same pages, same sign-on in every mode. A host is anything that can reach the storage bucket; an on-prem box is outbound-only, no inbound port, no SSH. Two boxes and one bucket survive the loss of either. Mechanics and caveats in the appendix.
residency
Residency is enforced where the instance wakes, not promised in a policy PDF.
Tito's three regions. The per-region bucket is reachable only by that region's hosts at the IAM layer. Replicated copies, blobs and logs follow the platform's retention window. No deployment is certified yet; the compliance appendix lists the evidence the system produces and the work remaining.
control
Pin a version, pick the moment you move, or ship your remix to your own channel and keep everything else.
Eleven has per-user update choice today; platform-wide it is next. Channels, promotion gates and the fork mechanics are in the appendix. The point: ownership is also who decides when the software changes.
people and agents
The same handler serves both. An agent cannot take a shortcut a person could not, and writes need a sentence a human would approve.
Actions opt in as typed tools; calls route through the app's own middleware. No bundled LLM client, no MCP: the agent surface is the app's actions. Every platform command is designed for someone with no access to the boxes. Details in the appendix.
building on it
One command from a branch gives you a canary behind your real sign-on, in seconds. Idle canaries sleep, so ten experiments cost almost nothing.
The canary verb landed on main 2026-09-04. A dev environment is a channel with one subscriber. Pipelines carry bake windows, passkey step-up and approvals.
evidence
Its own cloud account, hosts, storage and domains, on the published deployment modules.
The reference third-party self-hoster. Seapointish is a team ledger across Revolut, Wise and Stripe that replaced a hosted product. Restore figures from Tito's infrastructure README.
Same five-file shape for every app, open, forkable with sign-on, edge and trust tier intact. If you can read one CARLOS app you can read all of them.
how to start
The migration path: edge in front (Tito's Rails proof of concept did this), data home per region, idle parts hibernating, hot paths rebuilt as CARLOS apps. Each step is reversible. Detail in the appendix.
what is still young
One honest slide, plainly, before the close. Product-by-product status is in the appendix catalogue.
CARLOS
carlosframework.com · console.carloku.com
Close on the caption and the three properties an adopter cares about. Contact details to be added.
appendix
Mechanisms, numbers and status behind the slides before this one. Every unfinished thing is labelled.
Reference material for questions, not the pitch.
Appendix · architecture · two shapes
the framework · rastrillo
A Go program that compiles to one static binary and talks to one SQLite file. Five source files, a templates folder, server-rendered HTML, about 130 lines of JavaScript in total. Every app looks the same, so every app can be read, forked, and driven.
app = 1 binary + 1 database file + 1 hostname
the platform · carlos
An object-store bucket holds all durable state. Hosts run the carlos binary and converge on what the bucket says. A shared edge routes traffic. Idle instances park into the bucket and wake on the next request.
deployment = 1 bucket + N hosts + DNS
The framework is the shape of a CARLOS app the way the platform is the shape of the substrate it runs on. Apps that fit the shape get hibernation, residency, rollback, and an agent interface for free.
"One deployment is one object-store bucket + N hosts running the carlos binary + DNS" is verbatim from carlos/platform/README.md:10-13. Five-file app shape from oficina/calendar/AGENTS.md:8-22. 130 lines of JS from the rastrillo README.
Appendix · distribution · channels and versions
A customer who wants their own remix of a deployed app forks it, ships to their own channel, and points their instances at it. They keep the upstream sign-on, the edge, the hibernation and the trust tier. Upstream keeps shipping. The two never have to merge unless they want to.
That is an app store for organisations: one catalogue of apps, many channels per app, every instance deciding which one it follows. The pipeline that gates a promotion, with bake windows, passkey step-up and approvals, is what makes a channel safe to trust.
Mechanics from site/platform/index.html:211-216 (content-hashed releases, channels as pointers, instances subscribe and roll at the next natural boundary, "a channel with one subscriber") and pipeline.go (bake, passkey, approvals). Per-user pinning and choose-when-to-update is Eleven's feature per the founder (2026-09-07); it is not a platform-wide user-facing verb yet. "App store" is the deck's framing, not a term the repos use.
Appendix · development cycle
There is no staging system to keep in sync. A dev environment is a channel with one subscriber. One command from a branch builds, ships, makes a channel, spawns an instance and hands back a URL. Every push exercises the same path a release will take.
A canary instance sits behind production sign-on, on a production hostname, with production data shapes. A product manager no longer prototypes in an abstract external tool and then argues about what was meant. They open the canary, use the real thing, and say yes or no.
Canaries ship continuously in seconds, and a canary nobody is using hibernates like everything else, so ten open experiments cost roughly nothing. Promotion to a wider channel is gated by the pipeline: bake windows, passkey step-up, approvals. Rollback is a pointer.
The gap between "an idea" and "a thing real people can click, behind real auth" closes to the time it takes to compile. That changes who gets to try ideas, not just how fast.
"The dev pipeline is the prod pipeline" and "a channel with one subscriber" from site/platform/index.html:216. The canary verb landed on main 2026-09-04 (PR #384); Tito's go.tito.io has followed a canary channel as a live production channel throughout (internal/release/laddercheck_test.go). Pipelines: pipeline.go. "Product managers prototype in production" is the founder's framing (2026-09-07).
Appendix · security and trust
There is no team_id column in a CARLOS app because there is no second team in the database. Isolation is the operating system's boundary: an ephemeral system user per instance, its own SQLite file, its own hostname. Inside an instance, a row that is not yours answers 404, never 403. It does not exist.
Keymail, Eleven, Woodstar, Kass and amadan are end-to-end encrypted. Keys are made in the browser and never leave. The object store holds parked databases and blobs but no plaintext of any E2EE app. amadan proves it in CI: push a marker string, then grep the server's raw database bytes for it.
An app that must read data says so. Correomona reads every address it holds because an address must be plaintext to go in an envelope. Its named leaks are listed in the README and pinned by a test that fails when a new plaintext column appears without a dated reason.
The test for every app is the same: publish the database and see what leaks.
What that test proves: nothing readable is stored at rest. What it does not prove: key handling, authorisation logic, or a compromise of a live host. Those are the certification arm's job, later in this deck.
Sources: rastrillo/docs/site/scoping.md (404 not 403), internal/host/units/carlos-app@.service (DynamicUser), amadan/amadan/README.md (canary grep), correomona/AGENTS.md (plaintext test), pegamento/docs/doctrine.md:33 (publish the database).
Caveat for later drafts: the platform itself does not encrypt parked databases at rest. Sealing is done by the app using the framework's crypto, keyring and sealed-blob primitives. Secrets are sealed client-side before upload. Phrase as "no plaintext of E2EE apps", never "everything encrypted at rest".
Appendix · speed and durability
The wake figure is anecdotal across the family's apps; request percentiles are not yet benchmarked.
Numbers: RSS 20–60 MB from carlos-edge.service:66-68; binary sizes from the rastrillo README (fresh scaffold 21.3 → 14.7 MB raw, 10.6 → 5.1 MB compressed). Cold wake under 500 ms and the 1–2 s replication interval are the founder's figures (2026-09-07), not in any repo; worth a measured benchmark before the deck ships. No p50/p95 request figures exist.
Appendix · deployment modes
A member of an account brings an app live with a login alone. The console writes the manifest, pins the hostname, and the boxes converge in seconds.
A CARLOS host is anything that can reach the bucket. A remote host is outbound-only: port 443 out to storage and the edge tunnel, no inbound port, no SSH required. Your data bucket, your box, our routing.
The same OpenTofu modules the flagship uses are published for anyone. Two of the platform's first three deployments are self-hosted, so anything the flagship needs that a self-hoster cannot have is a design error, caught immediately.
No UX compromise because there is no second product: same hostname, same pages, same sign-on, only the bucket's address changed. Residency is enforced where the instance wakes, not promised in a policy PDF. And leaving is the design: point new boxes at your bucket and the platform is elsewhere; point them at another cloud's bucket and so are you. Who runs the bucket, the edge, sign-on and backups is a named choice in each mode, not a hidden dependency.
Sources: infra/remote-host.md (outbound-only), fleets.go and README.md:404-429 (customer fleets with own bucket), infra/README.md (published modules), tito/carlos-infrastructure/region-*.tf (per-region data bucket, IAM-enforced), platform site (residency quote).
Appendix · any host
A CARLOS host is anything that can reach the bucket: a cloud instance, a rack in a cupboard, a laptop, a board on a shelf. The platform depends on an S3-compatible object store and DNS, and that store can be a cloud's or one you run yourself. Everything else is optional; how many cloud services you use is a decision per deployment, not a requirement of the software.
Two hosts watching the same bucket survive the loss of either: the survivor claims the lease and wakes the instance from parked state, with no cluster software or quorum to run. What it still depends on is the bucket, DNS and the edge being reachable. And the caveat is physical: whoever can touch the box can read what is awake on it, so the trust tier and the room both matter.
Because a host is outbound-only and disposable, contributed machines can join a fleet from anywhere: a community's members, a university's departments, a co-op's offices, meshed through the edge tunnel. The bucket stays the source of truth; the compute is whatever people bring.
Nothing stops a deployment from using what the clouds do well. Latency-based routing sends a user to the nearest armed edge. Per-region buckets keep data where the law wants it. Same binary, same app, with or without the extras.
The floor is very low and the ceiling is very high, and it is the same software at both ends. Instances move between regions with their data following, two-phase, over a push-only staging prefix specced, in progress. The box is disposable, the bucket is not.
Sources: "a CARLOS host is anything that can reach the deployment bucket" and outbound-only hosts from infra/remote-host.md; lease claim and wake-on-any-eligible-host from the activator and platform site; latency routing via carlos steering ... latency (docs/site/cli.md:307-331); per-region buckets from Tito's infra. The two-box HA statement and the physical-security caveat are the founder's (2026-09-07). Pooled contributed compute and meshing are theoretical and marked so.
The flagship's bucket is AWS S3. Per the founder (2026-09-07) there has been extensive research into S3-compatible object stores for both blob storage and the replication stream; that research lives on the founder's laptop, not in these repos. The slide states S3-compatible as the target; keep "depending on use case" until a non-AWS deployment has run end to end.
Appendix · driveable by humans and agents
No bundled LLM client. Choosing a provider is your business. No MCP server in the platform. The agent interface is the app's own actions, exposed as typed tools, so it works with whichever model or none. A person using CARLOS without AI loses nothing. A person using it with AI gets an operator that can only do what the UI already allows.
Sources: rastrillo/docs/site/agents.md, docs/site/reference/tools.md (Dispatch through the mux, ConfirmSentence), carlos/platform/skills.go (well-known agent skills), skillmd_test.go (18,000 byte budget), AGENTS.md:49-53 (every command for a user with no infra access), completion-design spec ("MCP does not exist anywhere in the platform").
Appendix · scale · a hypothesis
An app moves along that curve by changing its manifest, not its architecture. Because the unit is an instance, growth is horizontal by construction: many users means many small databases waking when needed, not one database that must never fall over. Dineraya is built on exactly this: one instance per buyer, asleep in a bucket, so the network can fill in behind real purchases instead of needing a user base first.
This is a scaling hypothesis, not a load test. The largest fleet today is hundreds of instances. The next test is thousands, then the routing, storage-operation and fleet-administration limits at each step. Hibernation default is 15 minutes idle, tightening to 90 seconds.
"Scale is a declaration, not a rewrite" and the five-step curve are from the platform site. Idle window from internal/activator/activator.go:76,90; the 90 s target and "ten times a day" from the 2026-08-30 scheduled-ticks spec. The "billions" framing is a shape argument, not a load test; say so if asked.
Appendix · economics detail
Rate sheet defaults from internal/economics/scenario.go:141-164 (AppMonthUSD 5, InstanceHourUSD 0.01, free tier). $7.30 story from the scheduled-ticks spec §1 and PR #371. Heartbeat numbers from internal/lease/lease.go:26-36. Backhaul from docs/site/cli.md:681-684. The $5 and 1¢ are Carloku's rate-sheet defaults in code; Carloku is one provider in the ecosystem, and the flagship's real bill lives in the private infra repo.
Appendix · migrating existing apps
A conventional Rails or Django app runs behind the CARLOS edge unchanged, keeping its own sign-on wall. Tito's proof of concept did exactly this. You get the routing, certificates and fleet view first.
Give the app its own instance record, a per-region bucket, and a pool. Residency and restore rehearsals come with it: Tito restored seventeen databases in sixteen seconds from the bucket.
The admin screens, the reporting, the once-a-week job: split them into CARLOS instances that hibernate, and stop paying for them at 3am.
When a feature is worth owning outright, write it as a CARLOS app beside the old one. Same hostname family, same sign-on, faster, and it is yours.
Each step is reversible and each step pays for itself. The order is a real sequence, which is why it is numbered.
Step 1 from the rails-behind-carlos-edge POC spec (docs/superpowers/specs/2026-08-11-...) and Tito ID SSO proxying in apimode.go:153. Step 2 from tito/carlos-infrastructure/README.md restore rehearsal (17 DBs, 16.4 s). Steps 3 and 4 are the argued path, not yet a documented migration guide.
Appendix · the app catalogue, with status
| app | what it is | replaces | trust posture |
|---|---|---|---|
| Eleven | Team chat. One instance per space. The code quarry the platform came from. | Slack, Teams | End-to-end encrypted |
| Keymail | Email where keys live in the browser, one database file per inbox, and strangers pay proof-of-work for first contact. Also the family's sign-on. | Gmail, Outlook, Okta | End-to-end encrypted |
| Ocho in development | Personal messaging, forked from Eleven. Lives at ocho.chat. | Signal, iMessage, WhatsApp | End-to-end encrypted |
| Oficina | Office suite: docs, sheets, calendar, memory, files via Slopbox, single sign-on via Keymail. One instance per team. | Google Workspace, Microsoft 365 | Sealed per team |
| Woodstar | Social relays where follow lists are private and keys travel with the user. | X, Facebook, Mastodon servers | End-to-end encrypted |
| amadan | Git hosting and CI where the server cannot read your code. Hosts and gates the platform itself. | GitHub, GitLab, Actions | End-to-end encrypted, canary-tested |
| Correomona shipping this week | Mailing lists with consent recorded per list and checked at send time. No open pixels, no click rewriting, no engagement scores. One instance per team. | Mailchimp, Brevo | Server-side, named leaks tested |
| Dineraya proof of concept | Non-custodial payments over instant bank rails. One instance per buyer, one per merchant, a blind dispatcher. Nobody in the middle holds money. | Stripe, PayPal, card fees | Sealed to the buyer's passkey |
| Kass · Seapointish | Coaching, one instance per person. A team ledger across Revolut, Wise and Stripe. | Niche SaaS | E2EE · sealed single-tenant |
Ocho is not on this machine; per the founder it is a fork of Eleven for personal messaging at ocho.chat, so it inherits Eleven's E2EE posture. Dineraya is at bootstrap (one binary, three roles, CI gate, merchant canary live) and is openly a proof of concept. Correomona is due to be complete 2026-09-08 per the founder.
Sources: keymail/README.md, oficina/suite/README.md, pegamento/docs/doctrine.md, amadan/README.md, correomona/AGENTS.md, dineraya/README.md, paulca/seapointish/README.md.
Appendix · compliance · evidence and remaining work
No CARLOS deployment is certified yet, and no control mapping to ISO 27001 or SOC 2 has been written. The claim is narrower: the system already produces much of the evidence about data handling, in a form an assessor can re-run. The remaining work is a control mapping, a subject-access export, per-app deletion, a privacy policy and terms, and an assessor.
Ledger: carlos ledger verify, docs/site/cli.md:447-468. Console audit rows in internal/console/api*.go. Known gaps: no DPA, privacy policy or terms in any repo; no platform-level subject-access export; subscriber-level deletion in correomona is a dated not-yet. Sources: residency at IAM from Tito's region-*.tf and platform site; signed channel pointers, 72h bake, blind/seeing services from site/platform/index.html; device-code reasoning from README.md:136-154; consent from correomona/AGENTS.md; canary tests from amadan and oficina/home. The flag is important: nothing is certified, and the deck should never imply otherwise.
Appendix · features shipped and in progress
shipped today
working on
Every item on the left is a CLI command and an API call, designed for someone with no access to the boxes underneath. That is what makes the platform fully driveable by an agent as well as a person: if a task needs a human on a box, it is filed as a bug.
Shipped column verified against docs/site/cli.md section headings and the matching Go files on 2026-09-07. carlos canary landed on main 2026-09-04 (PR #384, "fill the reserved verb with the sugar over what already works"); the local checkout used for the first pass predated it. Deliberately omitted as not shipped: the blind services the site paragraph names (no code found), S3 cert cache (reserved).
"Working on": virus scanning, media hosting, error monitoring and analytics are the founder's list and appear nowhere in the repos yet. Instance moves (2026-08-28 spec), managed custom domains (2026-08-27 spec) are specced. Backup/restore today is operator-on-box only; webhooks exist only as an operator alert hook; search is not mentioned. Policy line: AGENTS.md:42, "if a day-to-day task has no API/CLI command, that is a product gap".