Infinite Slop’s tech stack: what is actually public

In an August 30, 2026 post, Pieter Levels said he built the site from his phone using Termius, a Hetzner VPS and Claude Code. His launch announcement credits fal sponsorship, and the original site links to fal's H3 Max model.

Those statements support a limited set of conclusions. They identify a remote terminal application, a server provider, a coding assistant and the credited video-generation provider. They do not by themselves establish the frontend framework, database schema, streaming protocol or moderation implementation.

It is tempting to turn a short build story into a full stack diagram. Resist that shortcut. A responsible diagram should separate named components from recommended components, with a clear boundary between the official project and your own design.

The same separation applies to other products. A code editor is not a queue, a VPS is not automatically a content delivery network, and a fast model does not automatically produce a stable live channel.

For your own implementation, document each service's responsibility and failure behavior. It is more useful than reproducing a list of brand names.

The sources reviewed for this guide do not provide an official public repository for the complete Infinite Slop service. We therefore do not claim to know its exact persistence layer, scheduler, deployment process, authentication design or input-to-model transformation.

The visible interface can establish that a queue exists. It cannot establish whether the backend uses SQL, a hosted queue, an in-memory process or another design. Similarly, a continuous-looking player is evidence of playback behavior, not proof of a particular streaming protocol.

If you encounter a repository called “Infinite Slop,” check the owner, license, linked announcement and maintenance history. A similar name or a convincing README is not enough to establish that it is the creator's official implementation. Never paste provider credentials into a demo whose operator you cannot identify.

A practical first version needs a server-side generation process, persistent job state, reviewed media storage and a simple viewer. The static guide you are reading can be served from an edge host; a video-generation pipeline has additional state and lifecycle requirements.

Choose technology your team can operate. A single persistent worker may be easier to inspect than several services at a small scale. As demand grows, separating scheduling, generation, review and delivery can help isolate failures. Either design still needs budget enforcement and duplicate-request protection.

Do not select a hosting package from a six-figure public-API cost example. Model API spend and hosting spend separately. The cost tool lets you enter operational costs, and the architecture guide explains where those costs arise.

The interesting lesson is that an existing model capability made a small interactive product possible quickly. It is not that every production responsibility disappeared because the interface was built on a phone.

A first implementation can demonstrate an interaction. A lasting service must also handle restarts, abuse, file retention, unexpected cost and support. Treat the launch story as an example of rapid experimentation, then use your own reliability and budget evidence to decide what is ready for public use.

If you only want to experience the format, open the original channel. If you want to build, start with a short, bounded show. You do not need to reconstruct private internals to test a useful version of the idea.