u/Independent_Yard3473

Hey r/SideProject,

I’ve been building Appaloft, an open-source deployment control plane for shipping small apps from local development to servers you own.

I started building it because my side projects kept ending up with random deploy scripts, server notes, recovery steps, and the classic “how did I deploy this last time?” problem.

Appaloft is meant to make deployment more repeatable. A project can start with one appaloft.yml file, then deploy static sites, local folders, Git repos, Docker images, or Compose apps through the same workflow.

The goal is that every deployment has a URL, logs, health checks, retries, redeploys, and rollback paths.

There is also an AI angle, but I’m trying to keep it practical: agents should operate through the same product boundary as humans, instead of being handed raw SSH, Docker, database, or provider access.

Current entry points include CLI, Web console, HTTP API, MCP tools, and an AI skill.

It’s still early, and I’m looking for feedback from people who actually ship side projects, demos, internal tools, or indie apps.

I’d love feedback on:

Is the positioning clear?

Would this fit your deployment workflow?

What would make you trust it enough to try it on a real project?

Website: https://www.appaloft.com

GitHub: https://github.com/appaloft/appaloft

Happy to answer questions or hear blunt feedback.

I’m one of the people building Appaloft, an open-source deployment control plane.

We wrote up how we’re using Bun in the public Appaloft repo. The most interesting part for us was not raw speed, but the release shape Bun made possible:

- TypeScript release scripts

- bun build --compile for the CLI/server

- embedded Web console and docs assets via file imports

- embedded PGlite runtime assets for the local-first path

- separate filesystem assets in Docker

- explicit macOS/Linux/Windows release targets

The part that surprised me: --compile gives you a binary, but it does not design your runtime asset boundary. We still had to decide how /docs works, how SPA fallback differs from docs routing, how operators override embedded assets, and why Docker wants a different asset strategy than a binary archive.

Blog post:

https://www.appaloft.com/blog/we-built-appaloft-with-bun/

Curious how other Bun users are handling compiled CLIs, embedded static assets, and multi-target releases.

I built Appaloft - Open-source deployment control plane for side projects

We built Appaloft with Bun: compiled binaries, embedded Web/docs assets, PGlite, and the parts that still hurt