I Open-Sourced the Portal I Built for a Client’s Vibe-Coded Apps

The Moment I Realized Vibe Coding Needed a Home

Last year, a client came to me with a mess. They had nine vibe-coded apps — small tools built with AI assistants like Claude and Cursor, each solving a specific problem: a customer feedback scraper, an internal expense tracker, a meeting summarizer. The apps worked, but they were scattered across GitHub repos, Replit projects, and local folders. The client’s team couldn’t find any of them without Slack messages. Worse, security was an afterthought — one app had API keys hardcoded into a public repo.

I knew vibe coding was exploding. Andrej Karpathy coined the term in early 2025, describing the practice of building software by describing what you want to an AI, then iterating on the output without deep code understanding. By 2026, it’s become a standard workflow for solopreneurs and small teams. But nobody had built a proper operational layer for these apps — a portal to manage, deploy, and monitor them.

So I built one. And after using it for six months across three client projects, I decided to open-source it. Here’s why, and how you can benefit from the same approach.

What Vibe Coding Actually Looks Like in Production

Let’s be specific. Vibe coding isn’t magic — it’s a process. You start with a prompt like “Build a Telegram bot that logs daily standup notes to a Google Sheet.” The AI generates a Node.js script with the Telegram API and Google Sheets API. You test it, tweak the prompt, and within 20 minutes you have a working bot.

But production is different. That bot needs:
- Environment variable management (no hardcoded secrets)
- Error logging (what happens when the Telegram API times out?)
- Scheduled execution (the bot should run at 9 AM daily)
- User authentication (not everyone in the company should post)

The portal I built solves these problems. It’s a lightweight dashboard that wraps any vibe-coded app (Python, Node.js, Go, whatever) with:
- Secret injection: Encrypted env vars loaded at runtime
- Health monitoring: Pings every 5 minutes, alerts on failures
- Deployment triggers: Git push → auto-deploy to a serverless runtime
- Access controls: Simple role-based permissions

The Real Case: From Chaos to Control

My client, a 12-person SaaS startup, had their vibe-coded apps running on random cloud VPS instances. One app was on a free-tier Heroku dyno that shut down after 30 minutes of inactivity. Another was on a developer’s laptop — if they went on vacation, the app died.

We migrated all nine apps to the portal. The process took two afternoons. Each app got a standardized Dockerfile (I wrote a template), and the portal’s CI/CD pipeline handled the rest. The results after three months:
- Zero unplanned downtime (down from weekly crashes)
- Deploy time per app: 45 seconds (down from manual SSH sessions)
- Onboarding new vibe-coded apps: 30 minutes (down from hours of infrastructure setup)

The team started treating vibe coding as a legitimate development workflow. They’d build a prototype in Cursor, push it to the portal, and have it in production before lunch.

Why I Open-Sourced It

I could have kept this as a proprietary tool. But I saw a pattern: every vibe coder I talked to had the same problem. The barrier isn’t building the app — it’s running it reliably. Open-sourcing the portal means:
- Transparency: Anyone can audit the security model
- Community improvements: Users already contributed webhook support and a Grafana dashboard template
- No vendor lock-in: Self-hosted on your own infrastructure (I use a $10/month DigitalOcean droplet)

The repo is at github.com/asibiont/vibe-portal (MIT license). It includes a docker-compose.yml for one-command startup, plus examples for integrating with Telegram, Stripe, and Google Sheets via API.

How to Use the Portal for Your Vibe-Coded Apps

Here’s a step-by-step from my own workflow:

1. Define the app’s interface

Every vibe-coded app must expose a health endpoint (e.g., /health) and a metrics endpoint (e.g., /metrics). The portal polls these to check status.

2. Store secrets in the vault

Use the portal’s CLI to inject secrets: vibe-cli secret set STRIPE_API_KEY sk_live_xxx. Secrets are encrypted at rest with AES-256.

3. Set up a deployment trigger

Connect your GitHub repo. The portal listens for push events to the main branch. On detection, it pulls the code, builds a Docker image, and deploys to a sandboxed container.

4. Monitor and alert

The portal sends Slack alerts on failure. I also set up a daily email with uptime stats. One client configured a Telegram bot to notify their team — ASI Biont поддерживает подключение к Telegram через API — подробнее на asibiont.com/courses.

5. Scale when needed

If an app gets popular (e.g., a customer-facing invoice generator), the portal can spawn multiple containers behind a load balancer. This is optional — most vibe-coded apps stay small.

The Numbers That Matter

I tracked metrics across 23 vibe-coded apps deployed via the portal (my own projects plus two clients). Data from May-June 2026:

These aren’t scientific — they’re from my own logs. But the pattern is clear: the bottleneck in vibe coding isn’t the AI, it’s the operational glue.

What Vibe Coding Needs Next

The portal solves the immediate pain point, but the ecosystem is still immature. I’d love to see:
- Native AI error handling: The portal could feed error logs back to an LLM to auto-generate fixes
- Standardized app templates: A registry of vibe-coded app blueprints (e.g., “Telegram bot + PostgreSQL”)
- Cost-aware scheduling: Automatically shut down apps that haven’t been used in 24 hours

The open-source community is already working on some of these. One contributor added a WebAssembly runtime for faster cold starts. Another built a simple A/B testing framework for vibe-coded UIs.

Should You Open-Source Your Internal Tools?

Not always. If the tool is your core differentiator, keep it closed. But the portal was never a product — it was infrastructure. Open-sourcing it gave me:
- Credibility: Clients trust a tool with public code reviews
- Free contributions: I got a Redis caching layer from a stranger on GitHub
- Network effects: Other developers suggest improvements I wouldn’t have thought of

If you’ve built a similar operational layer for your vibe-coded apps, consider sharing it. The community is small but growing fast. Your half-baked script might save someone a weekend.

Conclusion

Vibe coding is here to stay. By mid-2026, I’ve seen it used for internal dashboards, customer support bots, data pipelines, and even simple e-commerce tools. But the difference between a prototype and a reliable service is operational discipline. The portal I built — now open-source — provides that discipline without requiring a DevOps team.

If you’re vibe-coding apps right now, ask yourself: where are they running? How do you know they’re healthy? What happens when you’re on vacation? If the answers scare you, the portal might help. Try it, fork it, break it — and let me know what you build.