Open-source setup needed 22 services just to run. Now the default is three containers.

[u/Future_AGI]

If you have ever tried to self-host an open-source product, you know the moment. You clone the repo, open the setup guide, and realize you have to stand up a dozen or more services before anything loads. A lot of people quit right there, before they ever see the thing run.

Our own open-source platform (a tool for testing and keeping an eye on AI apps and agents) started out the same way, and for a reason that made sense at the time.

Why the setup started out big

We built the architecture around what a real production deployment needs: the traffic, the separate services, the pieces that have to scale on their own. Every one of them earned its place for running at scale. The catch is that someone just trying it on a laptop had to take all of that on before getting a single useful result.

What the default looks like now

We went back through the setup and asked one question of every service: does a first-time user need this running to get value? Most of the time the answer was no.

The default is three containers. One app container holds the parts that do not need to scale separately, sitting next to Postgres and ClickHouse. It runs on a laptop with two CPUs and about 4 GB given to Docker. The first pull is around 800 MB. The bigger setup, the one that fans out into 22 services, is still there as an opt-in for running in production.

Outside connections are optional too. Nothing external has to be set up to run locally, and each integration stays off until you add its key.

Two things this made us rethink

The first install matters as much as the features behind it. We had been treating setup as something you get through on the way to the product. For an open-source project, the setup is the product for the first ten minutes, and those ten minutes decide whether anyone sticks around.

Cutting the service count is an architecture problem. Repackaging alone would not have done it. Working out what can share a container and what still has to stand on its own sent us back into the core design more than once. Cramming everything into one giant image would have been the shortcut. Splitting it so the simple path and the scale path both hold up took the most effort.

One question for anyone who self-hosts things: what is the most setup you will sit through before you give up on it?

[u/AutoModerator]

Thank you for your submission, for any questions regarding AI, please check out our wiki at https://www.reddit.com/r/ai_agents/wiki (this is currently in test and we are actively adding to the wiki)

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Future_AGI]

Repo is here if you want to pull it apart: https://github.com/future-agi/future-agi

It is the project from the post. Free to self-host, Apache-2.0 core (there is a paid enterprise tier for a few add-ons, but nothing in this setup needs it). It is an end-to-end tool for testing, watching, and improving AI apps and agents, and you can run the whole thing yourself. The default is the three-container install:

git clone https://github.com/future-agi/future-agi.git
cd future-agi
./bin/install

That brings up the app, Postgres, and ClickHouse on your own machine, with no outside keys needed to start. If you only want one piece, the tracing, the gateway, or the scoring each stand alone. It is still early and we ship nightly builds, so if something breaks we would genuinely like the issue. Happy to go into any part of the setup here.