Building a Minimal PaaS-in-a-Box in 7 Hours

It all started on the morning of April 27th. While I was asleep, a close friend
forwarded me an open role for a Fullstack Infra Engineer at Brimble.

I woke up, replied, and immediately got to work. Looking at the requirements, I
realized I had a very tight window as I needed to get this submitted by 14:00. I
had attempted building a similar deployment engine in the past but didn't quite
cross the finish line. This time, with only about 7 hours on the clock, I had to
be extremely strategic about my execution.

Here is a breakdown of how I built a minimal PaaS (Platform as a Service) from
scratch between 07:00 and 13:45.

Choosing the Stack: Speed and Pragmatism

With limited time, my core philosophy was simple: do not reinvent the wheel.

My first step was researching Railpack, as required by the prompt, to understand
how it handles building OCI images directly from source code without needing
hand-written Dockerfiles.

For the backend, I needed a framework that provided as much out-of-the-box
utility as possible. I chose Encore.dev. Encore is phenomenal for rapid
infrastructure development because it natively handles boilerplate:
auto-provisioning Postgres, running database migrations, offering type-safe API
endpoints, and providing native WebSocket streaming out of the box.

By combining Encore (backend), Railpack (builder), Docker (container runtime),
and Caddy (dynamic reverse proxy), I was able to stitch together a fully
functional pipeline that takes a Git URL or tarball upload, builds it, runs it,
and exposes it to a public URL, all with live logs streaming directly to the
frontend.

Hindsight: What I Would Do Better

Shipping a working PaaS in under 7 hours requires making aggressive trade-offs.
If I had another weekend to expand on this, here is exactly how I would mature
the platform:

1. User Interface & Experience

While the current UI works, there is massive room for improvement. I really
admire Vercel's deployment dashboard and their "URL-first" design philosophy. I
would revamp the frontend to feel more like a seamless Single Page Application
(SPA) and improve the visual feedback during the build steps.

2. Infrastructure & Orchestration Improvements

• Zero-Downtime Redeploys: Currently, my pipeline uses a stopAndRemove
  followed by a runContainer approach, which causes about 1 second of
  downtime. A better approach would be to start the new container, wait for a
  health check to pass, swap the Caddy upstream route, and then spin down the old container.
• Build Cache Reuse: Railpack supports BuildKit's cache mounts. Exposing a
  persistent /root/.cache volume to the backend container would cut subsequent rebuild times dramatically.
• Scoped Deploy URLs: The current path-based routing (/d/<id>/) is the
  simplest solution that works, but it breaks user apps that rely on absolute
  paths in their HTML. The right fix is subdomain routing via wildcard DNS
  (<id>.localhost).
• Dropping the Sidecar Dance: Currently, the project uses a custom layered
  Dockerfile / backend-builder sidecar. This exists strictly because encore
  build docker needs the Docker daemon at build time. Ejecting and owning the runtime ourselves would let us drop ~60 lines of orchestration complexity.

3. Backend & Scalability

• Authentication: Right now, the API is entirely open. Encore's authHandler
  would slot in cleanly to secure the endpoints.
• Automated Deployments: Implementing GitHub webhooks to trigger automatic deployments on push.
• Log Management: Right now, log lines are persisted individually in Postgres.
  For long-running containers, the deployment_log table will balloon. A
  chunked layout, or pushing cold logs out to S3/MinIO, is the right
  architectural answer for anything beyond toy scale.
• Testing: The pipeline modules are highly mockable. I would add comprehensive test coverage around the cmd, caddy, and docker boundaries.

Platform Feedback for Brimble

As part of my application process, I didn't just build the take-home; I also
spent time dogfooding the actual Brimble platform. I encountered a few
interesting edge cases and UX hurdles during my testing.

Following the team's recommendation, I proactively reached out to Ileri
(@pipe_dev) via Twitter DM to share my findings and provide constructive
feedback.

Though I haven't received a response just yet, I'm really looking forward to
discussing these insights with the team.

Conclusion

Building this minimal PaaS was an incredibly fun and intense sprint. It forced
me to think critically about system architecture boundaries, developer
experience, and how to rapidly integrate tools like Caddy and Docker via APIs.

You can check out the source code for my submission here: Brimble

If you're building developer tools or infrastructure, I'd love to connect!