Attributes

CARLOS was developed via a software factory, AI-aware from the start, and as such, every decision was taken with the knowledge that agents would likely be driving as well as humans. Everything that can be done on the platform can be driven by an agent, and everything done by agents are disclosed via UIs and CLIs.

Compiling to a single binary requires the use of compiled languages, and compiled languages find errors at compile time. This gives a significant advantage over interpreted languages, particularly when agents are writing the code.

CARLOS apps tend to be as or more token efficient to apps built using e.g. equivalent frameworks in other languages, architectures, or frameworks, but come with all of the added benefits that CARLOS promises. Because CARLOS covers so much out of the box and targets the full-stack, and provides out of the box ways to get going, typically CARLOS apps should be quicker to build than the status quo tools.

CARLOS blurs the line between a web app and a CLI. CARLOS apps can be built such that the web app and the CLI are the same binary. This offers opportunities in portability and flexibility that would be hard to replicate in traditional layered-stack deployments. Testing things locally: run a local command. Pulling and pushing data back and forth is just copying files. Things that would have been dismissed as overly complex become trivial.

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 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.

Compiled languages can typically run tests an order of magnitude faster than interpreted languages. Coupled with tighter integration with e.g. chromedp in the Go ecosystem, and sharding of test suites, you can achieve significant test:code ratios with low suite wall-clock runtimes.

Because each copy of a CARLOS app is a full copy of the app with all its dependencies, the gap between feature-development and prototyping disappears. You can easily spin up 10 variants of the same feature, and run those either locally or in production or production-like environments and test with sample data in full fidelity.

Using lower-level system languages like Go and Rust means that you get massive performance out of programs that are extremely efficient. A moderate complexity Go app running on low capability consumer-grade hardware will typically achieve HTTP response throughput in the thousands of requests per second.

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.

A typical CARLOS Go app that hibernates on idle will wake from sleep in under 500ms, essentially imperceptible to the user. This allows you to build software that will be used by millions but compute is only active while they are.

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.

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.

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.

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 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.

For apps that require extra security, CARLOS provides trust classes, with CARLOS A encouraging server-blind data storage and on-device encryption. For apps that don’t need as much security, CARLOS still encourages sealed databases and encryption at rest for all data.

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.

If you use Rastrillo it comes with a set of security checks out of the box, and you can hook up CI to fail as any dependencies go out of date.

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.

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 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.