u/lugovsky

Hey,

Im part of a team working on a disposable app hosting service. We decided to build it because we kept facing situations where we needed a public HTTPS URL for a test API or web app, but getting one quickly wasn't always easy because of following reasons:

• We can't always deploy it within our existing infrastructure because of security policies
• Most cloud app hosting services require to sign up, verify email, and add a card

For use cases I mentioned, the ideal solution would be to get the app without signup or payment information knowing that it's getting disposed at some point. With AI coding agents this simply mean telling them something like:

Deploy this app to up.compartment.dev

My question is: would you use something like this for anything besides the testing scenarios I mentioned? If so, which ones?

Hi r/platform_engineering,

Disclosure: I’m one of the maintainers of Compartment, an Apache 2.0 open-source project.

Over the past few years, our team has accumulated more internal apps, scripts, workers, and automations. Building these tools has become much easier, but turning them into dependable team software still requires deployment, access control, secrets, isolation, observability, and ownership.

We wanted a small, self-hosted platform that provides those capabilities centrally rather than implementing them separately in every internal tool.

Our first beta used Docker Compose on a single host. After running it ourselves and with a few beta users, we concluded that this was the wrong long-term runtime. Failure recovery depended too heavily on one machine, the isolation boundary was weaker than we wanted, and supporting additional nodes would have meant gradually building our own orchestrator.

We therefore rebuilt the runtime around Kubernetes. This is a complete architecture change rather than a Kubernetes wrapper around the old deployment model.

The current design looks like this:

• Developers add a small compartment.yml and deploy through the CLI or a connected Git repository.
• Compartment owns the application-level model: organizations, projects, environments, releases, domains, variables, RBAC, SSO, audit logs, promotions, and rollbacks.
• Kubernetes owns the live runtime state.
• Projects are isolated using namespaces, RBAC, and network policies.
• Builds run as ephemeral rootless BuildKit jobs.
• Builds and tenant workloads run through a verified gVisor runtime boundary.
• Deployments are reconciled and rolled out without routing traffic to an unready version.
• The platform can provision a managed single-node k3s host or install into an existing Kubernetes cluster.
• With an existing cluster, the operator retains responsibility for nodes, ingress, storage, runtime configuration, and backups.

https://preview.redd.it/69rubs1tgxhh1.png?width=8164&format=png&auto=webp&s=e598afc584b3a6a2b503f58f216ef9d538ca2f1d

The intended use case is a controlled path for internal software that needs to become usable by a team without requiring every developer to understand Helm, ingress, certificates, workload identities, or namespace policy.

The design question we keep returning to is where the abstraction should end. We want developers to get a narrow, repeatable path from a repository to a running application, while platform operators retain control of the underlying cluster. At the moment, the application descriptor deliberately does not expose raw Kubernetes objects, node placement, or arbitrary pod configuration.

Would love to hear critical feedback from people who operate similar platforms.

GitHub: https://github.com/compartmentdev/compartment
Documentation: https://docs.compartment.dev/

I've started treating my AI-built apps differently.

If I build one polished public app, I'll use Vercel, Railway, Render, Fly, etc. The simplicity of a managed deploy flow is worth it. But a lot of my AI apps are not that kind of app:

• a scraper
• an admin panel for it
• a tiny CRM
• a webhook tester
• an invoice tool
• a dashboard for one client
• a background worker that runs a few times a day

These apps sit idle, then spike. Some have constant high CPU or DB usage. Some need to stay private. Some need to be shared with a specific set of people. Most do not deserve their own hosting setup.

The math gets weird once you have a pile, especially with heavy DB reads/writes to an external DB service like Supabase. Railway prices RAM at $10/GB/month and CPU at $20/vCPU/month. A 4GB / 2 vCPU always-on footprint can get expensive before traffic even matters.

A DigitalOcean 4GB / 2 vCPU VPS is $24/month with 4TB transfer. Hetzner and other VPS providers can be even cheaper. You trade away the managed platform, but you get one fixed bill and one box that can run many small apps. If you self-host your DB on the same VM, you can also remove most external transfer costs.

The setup I currently use:

• one VPS
• one wildcard domain
• Docker containers for each app, so one app does not affect another
• Caddy for HTTPS
• per-app CPU and memory limits
• one private login gate with SSO, so I do not need to rebuild that for every new app
• logs in one place
• automated deploys on merge from Git repos or a monorepo

You can build this yourself. It sounds complex at first, but Codex/Claude, Docker, and Caddy gets you far. But if you do not want to handle all this configuration yourself, I'm building an open-source project called Compartment around this pattern. It can be installed on a VPS and handle most of this for you.

I spend a lot of time looking at internal tools that started as spreadsheets, Airtable bases, SQL scripts, half-finished admin panels, or “temporary” manual ops processes that somehow became permanent.

If you have one of those workflows, drop it here and I’ll suggest a practical build path.

Useful context:

- What data source are you using now?

- Who needs access?

- What actions do users need to perform?

- What approval steps exist?

- What can go wrong if someone edits the wrong thing?

- Do you need SSO, RBAC, audit logs, or self-hosting?

- Is this internal-only or customer-facing?

- What have you already tried?

I’ll try to answer with:

- whether this should be a no-code/low-code app, custom code, or just a cleaned-up process

- what the data model probably needs

- what roles and permissions matter

- which parts are risky to automate

- what I would prototype first

I work on UI Bakery, so I’m obviously close to this space. But I’m not going to force every answer into UI Bakery.

I spend a lot of time looking at internal tools that started as spreadsheets, Airtable bases, SQL scripts, half-finished admin panels, or “temporary” manual ops processes that somehow became permanent.

If you have one of those workflows, drop it here and I’ll suggest a practical build path.

Useful context:

- What data source are you using now?

- Who needs access?

- What actions do users need to perform?

- What approval steps exist?

- What can go wrong if someone edits the wrong thing?

- Do you need SSO, RBAC, audit logs, or self-hosting?

- Is this internal-only or customer-facing?

- What have you already tried?

I’ll try to answer with:

- whether this should be a no-code/low-code app, custom code, or just a cleaned-up process

- what the data model probably needs

- what roles and permissions matter

- which parts are risky to automate

- what I would prototype first

I work on UI Bakery, so I’m obviously close to this space. But I’m not going to force every answer into UI Bakery.

The recent thread about IT becoming the cleanup crew for everyone's ChatGPT experiments got me thinking about the solutions for this problem. I don't think the issue is that people in marketing, ops, sales, or finance are using AI to build internal tools. That will happen, and some of those tools will be useful.

The problem is when a useful script on someone's laptop becomes part of the business, and then IT is expected to host it, secure it, debug it, and maintain it forever.

You can try banning this, but this would probably hurt business more compared to controlled rollout. I think the better model is:

• business teams own the tools they create
• IT owns the platform those tools run on

How I'd structure it:

1. Git as source of truth

No internal tool should live only in a zip, chat history, or random laptop folder. Each team gets a repo. If it changes, there is a commit. If it breaks, there is history.

2. Team sandboxes

Each team gets a constrained place to deploy small apps themselves: private URLs, SSO, logs, limited secrets, limited network access. Useful, but not production access by default.

3. Self-service deploys, not self-service infrastructure

Teams can deploy from Git into their sandbox. They should not be asking for random VMs, shared credentials, firewall exceptions, or "just keep this running."

4. Review based on blast radius

If the app needs customer data, write access, public routes, production credentials, or external email sending, that should trigger review. Not because it was AI-generated, but because it can cause damage.

5. Promotion for critical tools

Most tools can stay in the sandbox. If one becomes mission-critical, promote it properly: named owner, access review, logs/alerts, rollback path, support expectations. Maybe this is the time when IT gets responsible for this tool.

That feels like the missing middle: let teams automate their work, but make ownership and boundaries explicit.

I'd love to hear from people dealing with this problem right now: does this approach seem reasonable, or would it fail in your environment?

I'm working on an open-source project called Compartment that follows this model. Before we build too much around the wrong assumptions, I want to understand whether this is actually what people would want from this kind of tool.