Attributes

When using AI to build apps with CARLOS, creating the first version of an app typically takes hours. Incumbent apps can be migrated in a matter of weeks, with far better performance.

A CARLOS app can be distributed as a single binary that runs on a customer's computer on demand, or it can use e.g. CARLOS platform (or Carloku) to manage instance provisioning to get all of the benefits of SaaS without the dubious default data security posture, and the all-or-nothing deployment options. Self-hosting, hybrid-hosting, or cloud-hosting are all first class in the CARLOS ecosystem.

CARLOS apps should be multi-region by default. Any instance can be deployed to hosts in any region. With certain application choices, you get multi-edge by default too, for truly globally distributable apps.

By default, every CARLOS app process contains its full stack: Database, server, background jobs, HTML, CSS, and JS. This makes CARLOS apps extremely easy to reason about, even when they're distributed, decentralised, or produced by AI.

With AI driving, it's possible to essentially prototype your apps in real time. You can run multiple versions of the same app alongside each other trivially. Creating seed data is just a case of copying a file. You can deploy development, beta, and experimental releases to "production" alongside each other: every instance is completely isolated from the other.

CARLOS encourages data isolation from day one. Depending on the app, this could be instance-per-user, instance-per-team, instance-per-repo, or even many-to-many instances. Examples of all of these are in the apps gallery. Isolated data by default introduces huge benefits: debug customer data by pulling a copy of their instance (with permission, or pseudonymised). Move data between regions effortlessly just by copying files. A compromised database is limited to that tenant and only that tenant. If you choose E2EE: a compromised database yields nothing without the keys.

When every tenant gets their own process and database, you get decentralisation for free. Apps that feel like traditional monolithic SaaS apps can be completely decentralised. Apps can be assigned to URLs, or reverse proxied, or a combination of all of the above. Finally it's trivial for users of apps to have full control over where their compute and data live.

When every tenant has their own instance, the opportunities for customisation are infinite. Forking can be encouraged, and as long as an end customiser retains compatibility with the app ecosystem, folks can get last-mile customisability by creating their own version of any app. Further down the chain, since any instance can have its own URL, and the URL connects directly, apps that "feel" multitenant are completely separate, so customisation based on URLs is trivial.

CARLOS app instances are fully self-contained, so self-hosting is just running a binary, anywhere. Adding resilience is just connecting to an S3-compatible object store. For high availability, self-hosters can nominate another host to route to if theirs goes down, and ultimately communities can mesh compute to have truly "local" clouds. CARLOS makes this seemingly impossible goal as simple as running a process to register a fleet member.

The CARLOS platform and the apps built on it sit on the shoulders of many massive open-source products. CARLOS apps don't have to be open source, but the question is there: if anyone can write an app, and the open-source versions are better, why would we need any proprietary software?

CARLOS proposes that apps self-declare a trust class, with data isolation being the first rung, and that being a more secure default out of the box. App developers are encouraged to choose a trust class appropriate to the project, with peer-to-peer and E2EE at the top and hosted plaintext in a VPC at the bottom. Multi-tenant apps are possible, but discouraged in the CARLOS ecosystem.

CARLOS encourages building "glue services" that tend to be vault apps that don't require massive vertical scale. Adding a new "tenant" is always horizontal: you're adding a new instance to your fleet rather than adding rows to a giant database. Adding a new instance is managed by orchestrators and control planes, but because apps are processes, you won't find complex container orchestration: just the process management and isolation that Linux systems are already very good at.

CARLOS encourages the use of compiled languages: most of the examples are Go, but a CARLOS app can be implemented in any language that compiles to a single binary. Go, Rust, even Swift, OCaml, Mojo ... all of these are in play. Go gives an excellent balance of compile speed, runtime performance, library availability and maturity, all of which add up to CARLOS apps being highly capable out of the box, but also taking advantage of Go's massive HTTP concurrency support. CARLOS discourages JS frameworks: when views are rendered from the server in under 100ms, why waste time on the client assembling UI? CARLOS encourages using modern JS to create highly interactive apps, but using fast server responses to make server interactions imperceptible.

CARLOS apps can be produced in any language, any framework, but if you use Rastrillo, your apps should come out WCAG 2.2 AA compliance-ready. You'll still need a manual audit, but maybe the status quo will shift, with the cutting irony that good-for-AI is also good-for-accessibility.

CARLOS apps encourage multi-language support from day one, so apps can be geographically distributed from the moment they launch.

CARLOS is a set of patterns and architecture choices, not a prescriptive framework. Any language that compiles to a single binary can produce a CARLOS app, and can deploy to a CARLOS platform.