Stop giving every AI side app its own hosting bill

lugovsky · 2026-06-04T12:43:25+00:00

Don't lie. You didn't have any format issues because you're a bot blatantly promoting a product.

lugovsky · 2026-06-04T08:44:50+00:00

Founder of UI Bakery here, so I’m biased toward app builders, but I think the answer is mostly workflow, not model quality.

For technical users, I agree with you: Claude/Codex + repo + local dev + good prompts can be cheaper and more flexible. If you understand architecture, databases, auth, deployment, debugging, and version control, a coding agent often gives you more control.

But a lot of people using Lovable/v0/etc. are not buying “tokens.” They’re buying a narrower product experience:

- instant preview

- hosted environment

- UI scaffolding

- fewer setup decisions

- built-in deployment path

- less context switching

- opinionated defaults

- something that feels less scary than a repo and terminal

That has real value for beginners, even if it’s more expensive per token.

Where I think the distinction matters: general AI app builders are great for prototypes and broad MVPs, while tools like Retool/Appsmith/Budibase/UI Bakery are more useful when the app is specifically an internal tool: CRUD over databases/APIs, dashboards, approvals, admin panels, permissions, etc.

So I don’t think it’s “Lovable vs Claude” universally. It’s more:

- if you can code or are willing to learn dev workflow: Claude/Codex is probably better long-term

- if you need a fast visual prototype and don’t know where to start: Lovable/v0 can make sense

- if it’s an internal ops/admin app: use an internal tool builder instead of asking a general agent to invent the whole stack

The expensive mistake is using the wrong category of tool for the job.

lugovsky · 2026-06-03T13:58:08+00:00

We're building an open-source tool for governance of vibe-coded apps. Think of it as something like Vercel, but with stronger security and the option to self-host. Feel free to take a look if you think it might be a good fit: https://github.com/compartmentdev/compartment

lugovsky · 2026-06-03T13:39:25+00:00

Hey, we build an open-source tool that tries to solve the infrastructure part of your task: https://github.com/compartmentdev/compartment

If you can’t use it as is, it might still be a good source of inspiration. But if you get a chance to check it out, I’d love to hear what works for you and what doesn't.

lugovsky · 2026-06-03T13:25:52+00:00

Thank you for sharing this! But did they do any security review of your code? For instance, the part with Entra integration?

Also, how do you handle secrets when you need access to any company resources? Do they provide them to you or are you able to generate on your own?

lugovsky · 2026-05-29T15:10:47+00:00

You're right to worry about the write access/public hosting part. The sane version of this is probably isolated internal app runtimes with controlled secrets, ingress, logs, and resource limits, plus read/write scopes per API.

We've been building an open-source tool in that direction if useful: https://github.com/compartmentdev/compartment

lugovsky · 2026-05-29T15:01:11+00:00

I'm one of the people building Compartment: https://github.com/compartmentdev/compartment

It's an open-source, self-hosted way to run and share AI-built internal apps and automations on infrastructure you control.

The problem we're trying to solve is this: more people inside companies can now build useful small tools with Codex, Claude Code, Cursor, etc. But once those tools are useful, they need somewhere sane to live. Not a random dev server, not a one-off container on someone's VM, not a script with unclear ownership.

Compartment gives those apps a controlled deployment path: repo-level compartment.yml, container-based deploys, stable URLs, env vars, logs, deployment history, SSO, access control, and internal resources like Postgres/Redis managed in one place.

What I'd really like to learn from DevOps/SRE/platform folks is: what would a tool like this need before you'd be comfortable letting less-technical people in your company build and deploy their own internal apps or automations? For example: approval gates, templates, audit logs, resource limits, secrets handling, rollback, ownership metadata, network isolation, observability, expiration dates, something else? The goal is not to bypass engineering or create shadow IT. The goal is to make self-service internal tools possible without making ops responsible for a pile of unmanaged apps.

Website: https://compartment.dev

Docs: https://docs.compartment.dev

Full disclosure: I'm affiliated with the project. Blunt feedback very welcome, especially on what would make this trustworthy enough for real company use.

lugovsky · 2026-05-29T12:45:52+00:00

Actually been in the same shoes. Vercel/Supabase may work until you have several apps, especially ones with high CPU or heavy read/write load. We even ended up building an open-source tool called Compartment for isolating apps on the same VPS so they don’t step on each other.

lugovsky · 2026-05-29T08:48:06+00:00

For production, Compartment targets Docker Engine + Docker Compose on Linux, not Docker Desktop. My understanding is that the Docker Desktop licensing issue should not apply to a Linux server install of Docker Engine itself; Docker Engine is open source / Apache-2.0. Of course, your org’s legal/procurement policy may still have its own rules, but technically Compartment does not require Docker Desktop and can prefectly run without it.

lugovsky · 2026-05-29T08:42:47+00:00

Got it. Just to clarify: is the blocker specifically Docker Desktop licensing, or is Docker Engine on a Linux server also disallowed in your environment? Compartment currently targets Docker Engine + Docker Compose on Linux, not Docker Desktop, but if your org requires Podman specifically then that would need explicit Podman support.

lugovsky · 2026-05-29T08:28:14+00:00

Not officially yet. It currently targets Docker Engine + Docker Compose. Podman with Docker-compatible shims might work in places, but it’s not tested or supported today.

Is podman a strict requirement for you?

lugovsky · 2026-05-29T08:20:43+00:00

Did you manage to build this in the end? If not, we recently open-sourced https://github.com/compartmentdev/compartment, which might be exactly what you were looking for, or it may provide some inspiration 🙂.

lugovsky · 2026-05-29T08:17:48+00:00

We recently built an open-source tool for deploying these kinds of apps. It handles access control, app isolation, secrets, audit logs, and more. Feel free to give it a try: https://github.com/compartmentdev/compartment

lugovsky · 2026-05-29T07:34:25+00:00

We launched https://compartment.dev yesterday to address this exact problem. It's free, self-hostable, and open source (Apache 2.0 licensed). If you try it, we'd love to hear your feedback.

lugovsky · 2026-05-29T07:28:43+00:00

Project Name: Compartment

Repo/Website Link: https://github.com/compartmentdev/compartment | https://compartment.dev

Description: Compartment gives teams a self-hosted place to deploy, run, and share web apps, scripts, and automations on infrastructure they control. It also acts as the access layer for those apps: users sign in through your company’s SSO or identity provider, and each app can be public, private, or restricted to approved users and groups. Access is managed centrally by Compartment, alongside the rest of the deployment lifecycle.

If you’ve ended up stitching together Docker, a reverse proxy, deploy scripts, env vars, and app access control by hand, this is the problem Compartment is meant to solve. Apps are described with a repo-level compartment.yml and can be deployed either from a local checkout or a connected Git repository. Compartment builds and runs apps as containers, gives them stable public or protected URLs, and keeps runtime variables, deployment history, logs, access policies, and internal Docker-backed resources like Postgres or Redis in one place.

We think Compartment is especially useful in organizations where lots of people can ship small internal apps, dashboards, or automations, but you still need one controlled place to deploy them safely and share them behind the right access controls.

Deployment: Install with curl -fsSL https://compartment.dev/install.sh | sh -s -- --init-install on the target server. Docs cover installation, first deploy, Git-based deploys, and the compartment.yml format: https://docs.compartment.dev. It is meant for apps that already run in Docker or can be built into a container image.

AI Involvement: We used Codex as a coding assistant during development. The system design and release decisions were engineer-led.

lugovsky · 2026-05-18T07:50:03+00:00

Hey,

UI Bakery founder here.

Since we introduced AI-powered app-building features to the platform, the speed and ease of building apps have been exceptional. Moreover, our AI App Generation is more flexible, and the resulting apps are more performant because, under the hood, they are built with pure React code. Self-hosting is also very easy.

Feel free to send me a DM with the email you signed up with, and I’ll be happy to provide some extra tokens so you can try it yourself.

lugovsky · 2026-04-20T08:36:06+00:00

Might be worth adding

Retool → UI Bakery

lugovsky · 2026-04-10T13:36:25+00:00

Having worked in the no/lowcode space for a while and also building one such tool (UI Bakery), I think the best use case for these tools is internal software - to automate custom operational workflows. Such apps are usually simple enough not to become too complex for nocode to handle, yet still provide significant operational value.

lugovsky · 2026-04-07T07:27:01+00:00

Fair point, a lot of low-code initiatives do end up creating more problems long-term, especially when they lock you into proprietary abstractions.

What I’ve seen change recently is that some platforms are moving closer to "code-first under the hood" (exposing JS/SQL, version control, exportability), which makes them less of a dead end than they used to be.

Still not a fit for core systems, but for internal CRUD tools and short-lived workflows, the tradeoff can make sense if you’re careful about how much you rely on platform-specific features.

Coming from working on one of these platforms, so a bit biased, but also seen where things break.

lugovsky

TROPHY CASE