Introducing Moul Devlog

Why I am building Moul: a self-contained, single-binary backend stack that eliminates distributed infrastructure complexity.

Phearak S. Tha
Phearak S. ThaFounder

I am building Moul to simplify how we run application backends without the overhead of fragile cloud architectures. Setting up background queues, event analytics, database backups, and image processing pipelines usually requires stitching together multiple paid services.

To get a simple web application running today, you rarely just write code. You configure an S3 bucket, set up background queues, configure a worker process, integrate third-party tracking scripts, and manage cron jobs for database backups. This distributed complexity is exhausting. It forces developers to spend more time debugging cloud infrastructure than crafting the actual application.

The Single Binary Philosophy

Moul takes a different path by baking these essential primitives directly into a single compiled binary. It runs anywhere. It requires no external orchestration. It just works.

Here is the stack I am embedding:

  • Integrated Job Queue: A database-backed worker engine, heavily inspired by Elixir's Oban.
  • Autogenerated API Endpoints: Data routes that construct themselves automatically from your database schema, similar to PocketBase.
  • First-Party Analytics: An embedded event tracker inspired by Ruby's Ahoy, storing client analytics directly in your database.
  • Automated Backups: Zero-config1 database snapshots pushed to your object storage on a schedule.
  • Media Pipelines: On-the-fly image optimization and Thumbhash generation built directly into the binary.

Having all of this in a single binary means you can deploy the entire stack to any server with a single command. It eliminates the configuration drift and network latency of external dependencies.

Ultimately, this isn't about marketing hype or trying to disrupt the cloud. It is about restoring a sense of sanity and self-reliance to software engineering. Building should feel direct, and the systems we build should be resilient enough to run for years on a single, modest virtual private server without constant maintenance.

This model won't fit every scale. High-traffic systems with distinct performance bottlenecks will still need decoupled infrastructure. Yet, I am convinced it covers a much wider range of applications than we typically assume. That is the kind of engineering I want to return to.

Footnotes

  1. Apart from the S3 configuration and backup location, of course.