Vibe coding a VestaCP alternative

mikho

This is a placeholder for things to come.

It will be a journey, and I want you all with me.
I will make some decisions that probably will make you all question me as a person.

Well, we all have our preferences; sometimes we don't agree, and that is fine.
The initial plan for this "fun" project is to vibe-code most parts. Manual edits of files will be kept at a minimum.

I will share some of the prompts, often the larger ones that make a lot of changes to the codebase.
Plans will be shared here, and of course the GitHub URL.

All when available.
I'm writing this to let you know about the plan. I hope there will be some updates later tonight.
Right now I have other pressing business to attend to.

Chievo

Enjoy ! Have fun ! And enjoy again .

AnthonySmith

This is going to be fun.

Jord

Vibe the vibe, it will be fun

Falzo

Best of luck :-)

cmeerw

@mikho said: The initial plan for this "fun" project is to vibe-code most parts.

What set up are you planning to use? agent, model, expected costs?

mikho

@cmeerw said:

@mikho said: The initial plan for this "fun" project is to vibe-code most parts.

What set up are you planning to use? agent, model, expected costs?

This will be coded by Claude, my AI-assistant. The models and efforts will vary, depending on how many tokens I have left on my company account.

I had very little time this evening, so I started by putting on the Plan hat on Claude, feeding this prompt.

 I'm planning on rewriting the web hosting panel which has the code in this github repository: [https://github.com/outroll/vesta](https://github.com/outroll/vesta)

I ran a control of the code and the report can be found here:  [https://claude.ai/code/artifact/02e8efc5-13e6-4ba2-9edc-a51139a391c8?org=70e79a25-81f8-4951-9038-c9caa45b0fc2](https://claude.ai/code/artifact/02e8efc5-13e6-4ba2-9edc-a51139a391c8?org=70e79a25-81f8-4951-9038-c9caa45b0fc2)

The codebase will be done with latest, stable version of Laravel and React.

The UI should be similar to the original project but the backend should be completly re-written because of all the vulnerbilities and bad decisions made in the original code.

Act like a senior technical lead managing a real engineering team.

Before writing code:

- Ask clarifying questions
- Challenge bad decisions
- Identify scaling risks
- Suggest better approaches
- Prioritize simplicity

Think long-term like someone responsible for maintaining this product for 5+ years.

Then provide:

- Technical decisions
- Tradeoff analysis
- Recommended architecture
- Implementation plan
- Production-ready solution

"You are now 4 elite Al agents working together on the same project:

- Architect
- Engineer
- Reviewer
- Optimizer

Each agent has a specific role:

- Architect → Design scalable system architecture
- Engineer → Build the implementation
- Reviewer → Perform senior-level code review
- Optimizer → Improve performance and scalability

Workflow: Architect designs the system

Engineer builds it

Reviewer critiques and improves it Optimizer makes it production-grade Finally provide:

- Complete architecture
- Full implementation
- Review feedback
- Final optimized version

Think and collaborate like a world-class engineering team building a real startup product.

And after many, long, boring minutes ..... this plan was formed, almost 2500 words.

Plan: LESta Hosting Control Plane Rewrite

TL;DR: Rebuild the Vesta product as a Laravel 13.17 and React 19 control plane, preserving the compact hosting-panel workflows while replacing privileged PHP shell execution, flat-file state, wildcard sudo, and executable queues. The first implementation milestone is a complete web-hosting vertical slice on Ubuntu LTS with a Go node agent boundary. Mail remains an MVP capability, but is isolated as a separately gated subsystem because it carries the highest abuse and operational risk.

Steps

Phase 0, decisions and product contract

1. Pin the legacy Vesta reference commit and create a capability matrix from src/react/src/containers/ControlPanelContent, src/react/src/components/MainNav, web/inc/i18n/en.php, web/add, web/edit, web/delete, web/suspend, web/api/v1, bin/v-*, data/packages, and data/users. Record resource fields, lifecycle verbs, quotas, suspension semantics, role visibility, and cross-resource effects. Treat the Claude artifact as supplementary only because it is not publicly readable from this environment.
2. Define the supported first-release environment: Ubuntu LTS, one managed node, self-hosted web/DNS/mail/database services, provider administrators plus customers, fresh installs, no billing, and no promise of importing existing Vesta installations. Reserve a later migration tool, but do not let compatibility force unsafe legacy behavior into the new runtime.
3. Write the threat model and trust boundaries before host integration: browser to Laravel, Laravel to agent, agent to operating system/services, tenant to tenant, and backup/secret storage. Establish non-negotiable prohibitions: no generic RunCommand, no arbitrary command-plus-arguments API, no exec from controllers, no wildcard sudo, no raw user filesystem paths, no secrets in props/logs/job payloads, and no executable queue files.
4. Resolve the database decision as an explicit ADR. MySQL/MariaDB is a confirmed requirement, so target MySQL 8.4 or MariaDB 11 compatibility, use strict SQL modes, foreign keys, indexed ownership/status/name fields, transactional outbox tables, and application-level constraints where PostgreSQL-specific features would otherwise be tempting. Revisit PostgreSQL only if reporting, locking, or JSON/query requirements prove materially painful.

Phase 1, control-plane foundation

5. Extend the existing Laravel foundation with relational aggregates for accounts, memberships, roles, permissions, hosting packages, package limits, nodes, node capabilities, IP allocations, audit events, idempotency receipts, outbox messages, and provisioning operations. Keep authentication identity separate from hosting ownership and resource state.
6. Keep Fortify, passkeys, email verification, 2FA, secure session rotation, login throttling, password confirmation, and reauthentication for destructive actions. Add deny-by-default policies for provider administrators, customer accounts, and every owned resource. Do not reproduce Vesta's implicit session.look user switching without an explicit, audited impersonation model.
7. Build application actions and query services behind thin controllers. Every mutation validates and authorizes at the boundary, updates desired state transactionally, writes an audit record, creates an idempotency receipt where appropriate, and dispatches provisioning work after commit. Use named route/controller contracts and regenerate Wayfinder after route changes.
8. Define a versioned node protocol. Each operation has a named capability, strict schema, resource ID, desired-state version, idempotency key, deadline, request digest, correlation ID, and structured result. The agent authenticates using short-lived bootstrap exchange followed by per-node mTLS with certificate rotation and revocation.

Phase 2, first vertical slice, web hosting

9. Model web hosting with normalized domains, aliases, node assignment, IP allocation, web template reference, certificate metadata, suspension state, provisioning state, desired-state version, observed-state digest, and usage snapshots. Normalize DNS names and IDN input, enforce package quotas, and preserve Vesta's user-visible lifecycle without preserving its shell command names.
10. Implement WebProvisioner and a fake adapter first, followed by the Go agent capability for staged configuration rendering, ownership and permission assignment, syntax validation, atomic activation, service reload, health check, and rollback. Laravel must never execute host commands directly. Operations must be bounded, idempotent, retryable, observable, and safe after lost responses.
11. Add authenticated Inertia routes and React pages for web-domain list, create, edit, suspension, deletion, search, pagination, and provisioning status. Use the existing app layout and UI primitives, typed Wayfinder helpers, Inertia forms, validation errors, flash notifications, loading/empty/error states, responsive tables, and explicit destructive-action confirmation.
12. Add focused Pest coverage for authentication, policy denial, tenant isolation, domain normalization, uniqueness, quota enforcement, lifecycle transitions, transaction rollback, after-commit dispatch, idempotency, fake adapter payloads, redacted logs, and provisioning failure visibility. Add browser coverage for the primary list/create/edit workflow and JavaScript-error smoke checks when browser tooling is available.

Phase 3, core resource slices

13. Add DNS as a full slice with zones, records, nameservers, type-specific validation, ownership policies, suspension behavior, and a typed DNS provisioner. Validate duplicate/conflicting records, generated configuration, eventual failure, retry, drift, and rollback.
14. Add mail as a separate capability group, not incidental domain CRUD. Model mail domains, accounts, aliases, forwarding, autoreplies, quotas, DKIM keys, TLS settings, delivery queue state, abuse controls, and credential rotation. Isolate Exim/Dovecot, spam/antivirus, DKIM material, mail queues, and mailbox storage on the node. Require rate limits, bounce/abuse monitoring, resource quotas, secret redaction, and explicit operational health gates before enabling self-hosted mail for customers.
15. Add managed databases with database hosts, database instances, encrypted credential metadata, type/charset/host validation, rotation, quota enforcement, queued create/drop/update operations, and no credential exposure through Inertia responses or logs. Use native database protocols or a tightly scoped agent capability, never interpolated SQL from user input.
16. Add cron with normalized schedule fields, ownership, status, suspension behavior, execution history, and an explicitly defined command policy. Prefer a catalog of supported tasks or an isolated account-scoped runner. Reject privileged commands, unsafe interpreters, unbounded output, and cross-account paths.

Phase 4, higher-risk operations

17. Add filesystem access only through an account-root abstraction. Canonicalize paths, reject traversal, symlink and hard-link escapes, special files, unsafe archives, excessive depth, and unbounded transfer sizes. Stream uploads/downloads, audit changes, and keep file manager permissions separate from host-agent privilege.
18. Add backups and restores with encrypted, integrity-checked, versioned artifacts in object storage, retention policy, access control, resumable transfer, isolated restore staging, and recurring restore drills. Replace Vesta pipe files and process scans with scheduler-dispatched unique jobs, durable states, backoff, dead-letter handling, and notifications.
19. Add provider operations for nodes, capabilities, service health, IP pools, controlled firewall rules, status/restart/config-test actions, and package/template administration. Restrict these to operator policies, explicit capability allowlists, concurrency locks, rollback, and a complete audit trail. Defer unrestricted service editors and arbitrary firewall rules until separate threat models pass review.
20. Add usage and statistics as incremental snapshots and read models, not repeated scans or manual counters. Paginate large histories and logs, eager-load dashboard relationships, and monitor queue backlog, node heartbeat age, mail queue depth, backup throughput, config failures, drift count, and lock contention.

Phase 5, frontend parity and operations

21. Extend the existing Inertia shell with role-aware navigation, account context, breadcrumbs, resource counters, search, notifications, and asynchronous operation feedback. Preserve Vesta's vocabulary and compact list/detail/add/edit workflow, but use modern accessibility, responsive behavior, keyboard support, and clear state transitions.
22. Organize reusable React code under resources/js/components/{web,dns,mail,databases,cron,files,server,backups} and page props under resources/js/types. Use generated @/routes and @/actions for every backend call. Keep global Inertia props limited to authenticated identity, current account, permissions needed for navigation, and flash data.
23. Run Laravel statelessly behind HTTPS. Use MySQL/MariaDB for authoritative state, Redis for queues/cache/locks/rate limiting, and object storage for backups and large artifacts. Operate scheduler and workers independently with health checks, bounded concurrency, retries, dead-letter states, metrics, centralized structured logs, and alerting.
24. Replace curl-to-root installation with a signed, pinned deployment process for the control plane and Go agent. Publish checksums and SBOMs, verify provenance, use staged upgrades and health checks, retain rollback generations, and never silently replace an existing host configuration.

Phase 6, review, optimization, and release

25. The Reviewer gate checks authorization matrices, tenant escape, CSRF, MFA, rate limits, replay rejection, schema fuzzing, injection resistance, path/archive attacks, secret redaction, mail abuse controls, backup access, certificate rotation, signed-update rejection, and least-privilege agent permissions.
26. The Optimizer gate checks MySQL query plans and indexes, N+1 behavior, pagination, queue throughput, per-node serialization, batching/debouncing of config changes, large artifact streaming, cache invalidation, noisy-neighbor limits, and horizontal control-plane scaling.
27. Add CI checks for migrations, Pint, PHPStan, ESLint, Prettier, TypeScript, focused Pest suites, full tests, production Vite build, dependency/security scanning, and agent tests. Rehearse empty-database deployment, node bootstrap, agent offline behavior, duplicate delivery, lost response after mutation, invalid config rollback, disk-full handling, backup restore, and release rollback.
28. Only after shadow/reconciliation and failure drills succeed should a later migration tool import Vesta data. It should be idempotent, dry-run by default, produce a field/error report, and never execute imported commands or trust imported paths. Legacy API deprecation and removal are outside the first vertical slice and require a separate cutover plan.

Relevant files
- /Users/mikho/Herd/LESta/composer.json and /Users/mikho/Herd/LESta/package.json, current Laravel 13.17, Inertia 3, React 19, Fortify, Wayfinder, Pest, and Tailwind 4 baseline. Do not add dependencies without approval.
- /Users/mikho/Herd/LESta/routes/web.php and /Users/mikho/Herd/LESta/routes/settings.php, authenticated Inertia route boundaries and settings conventions.
- /Users/mikho/Herd/LESta/app/Models/User.php and /Users/mikho/Herd/LESta/app/Http/Middleware/HandleInertiaRequests.php, identity and minimal shared props.
- /Users/mikho/Herd/LESta/app/Actions/Fortify/, /Users/mikho/Herd/LESta/config/fortify.php, and /Users/mikho/Herd/LESta/app/Providers/FortifyServiceProvider.php, existing authentication extension points.
- /Users/mikho/Herd/LESta/database/migrations/, /Users/mikho/Herd/LESta/database/factories/, and /Users/mikho/Herd/LESta/app/Models/, ordered schema, factories, relationships, casts, and lifecycle state.
- /Users/mikho/Herd/LESta/app/Http/Controllers/, /Users/mikho/Herd/LESta/app/Http/Requests/, /Users/mikho/Herd/LESta/app/Policies/, and /Users/mikho/Herd/LESta/app/Actions/, thin HTTP boundaries, validation, authorization, and use cases.
- /Users/mikho/Herd/LESta/app/Jobs/, /Users/mikho/Herd/LESta/app/Events/, /Users/mikho/Herd/LESta/app/Listeners/, /Users/mikho/Herd/LESta/app/Console/Commands/, and /Users/mikho/Herd/LESta/routes/console.php, durable provisioning, outbox processing, usage, backups, and scheduler integration.
- /Users/mikho/Herd/LESta/app/Contracts/ and /Users/mikho/Herd/LESta/app/Services/, typed provisioner contracts, agent client, idempotency, secrets, path safety, and query/read services.
- /Users/mikho/Herd/LESta/resources/js/app.tsx, /Users/mikho/Herd/LESta/resources/js/layouts/, /Users/mikho/Herd/LESta/resources/js/pages/, /Users/mikho/Herd/LESta/resources/js/components/, /Users/mikho/Herd/LESta/resources/js/types/, and /Users/mikho/Herd/LESta/resources/css/app.css, the existing Inertia shell, pages, reusable UI, types, and theme.
- /Users/mikho/Herd/LESta/resources/js/routes/, /Users/mikho/Herd/LESta/resources/js/actions/, and /Users/mikho/Herd/LESta/resources/js/wayfinder/, generated route/controller contracts, never hand-edited.
- /Users/mikho/Herd/LESta/tests/Pest.php, /Users/mikho/Herd/LESta/tests/Feature/, /Users/mikho/Herd/LESta/tests/Unit/, and /Users/mikho/Herd/LESta/tests/Browser/, feature, unit, architecture, and browser coverage.
- /Users/mikho/Herd/LESta/.github/workflows/, CI and release checks. The Go agent should be a separately versioned deployable component, not embedded in Laravel request execution.
- Legacy references: https://github.com/outroll/vesta paths bin/, web/api/v1/, data/packages/, data/users/, install/, src/deb/, src/rpm/, and src/react/src/. Use them for contract extraction only, never as implementation templates.

Verification
1. Before implementation, approve the threat model, capability matrix, MySQL/MariaDB version target, Ubuntu LTS version, mail stack support matrix, and first-slice acceptance criteria.
2. For the web slice, run the narrow Pest tests first, then Pint, PHPStan, ESLint, Prettier, TypeScript, Wayfinder generation, and the production Vite build.
3. Assert every mutation is policy-authorized, transactionally persisted, dispatched after commit, idempotent under retry, serialized per resource/node where required, and visible as a structured provisioning state.
4. Run security tests for tenant isolation, CSRF, MFA gates, rate limiting, command injection, path traversal, archive extraction, secret redaction, agent authentication, replay, and privilege boundaries.
5. Run reliability tests for duplicate operations, lost responses, offline agents, stale versions, invalid service configuration, rollback, partial subsystem failure, disk-full, backup corruption, and restore.
6. Manually verify the primary React workflow at desktop and mobile widths, role-aware navigation, loading/error/empty states, destructive confirmations, dark mode, accessibility, and absence of browser JavaScript errors.
7. Before production, rehearse signed installation, node bootstrap, database migration, queue/scheduler health, backup restore, alerting, rollback, and controlled feature enablement.

Decisions
- The requested first release is core hosting plus self-hosted mail, not billing.
- Deployment starts as one Ubuntu LTS node but every resource is node-assigned and the protocol is multi-node ready.
- Provider administrators and customers are the initial tenancy model. Reseller nesting is reserved until the account/membership model is proven.
- MySQL/MariaDB is a hard requirement. PostgreSQL is not used unless a later ADR changes the decision.
- A Go system service is the recommended node-agent implementation.
- Fresh installs are the initial migration strategy. Vesta import/coexistence is later and dry-run first.
- Web hosting is the first implementation milestone. Mail is MVP scope but must be gated behind its own capability, threat model, and operational readiness review.
- Preserve UI vocabulary, navigation patterns, and resource workflows. Do not preserve legacy URLs, shell command names, flat-file state, or unsafe privilege assumptions.
- No production implementation should begin until this plan is approved. No commit or branch creation is part of this plan.

Tradeoff analysis
- MySQL/MariaDB meets the stated requirement and is familiar in hosting environments, but PostgreSQL would provide stronger native constraints and more flexible reporting primitives. The design compensates with strict schema constraints, indexed relational read models, and explicit application services.
- A Go agent adds a second deployable component and release pipeline, but it creates the necessary privilege boundary and keeps Laravel horizontally scalable. A PHP/Bash adapter would be faster only for a prototype and would recreate the main risk.
- Self-hosted mail preserves Vesta parity and customer control, but it creates abuse, reputation, deliverability, storage, and incident-response obligations. It is therefore isolated, quota-limited, observable, and gated rather than mixed into generic domain provisioning.
- A relational source of truth plus asynchronous reconciliation is more complex than direct config writes, but it enables transactions, retries, auditing, drift detection, rollback, multi-node growth, and recoverable failures.

Scope boundaries
- Included in the plan: authentication, authorization, accounts, packages, quotas, web, DNS, mail, databases, cron, backups, node health, typed provisioning, audit, responsive React UI, testing, and production operations.
- Excluded from the first implementation slice: billing, Vesta import, broad OS support, reseller nesting, unrestricted file manager, arbitrary firewall/service editors, plugin marketplace, and full multi-node failover.
- The current environment does not contain the legacy Vesta checkout, and the linked Claude artifact is unavailable without access. Exact field mappings and vulnerability claims must be confirmed against a pinned commit and representative production data before migration work.

Tomorrow I will read all these words, form an opinion on the content, and probably run a couple of more prompts on it before any code is written.

Question to the audience .... should the original UI be kept or should a more modern UI be built?

jarland

I've been accused of "vibe coding" enough that I have to defend myself in advance every time I talk about it. I do not "vibe code" anything that meets two requirements: public facing, contains or can access anything of consequence.

But when the job is something where you compromising it just makes me laugh and delete it, it's super fun to just explain what you want, sit back, and watch it go. It's easily as entertaining as a good movie. I've got a ton of projects just sitting in a folder that were vibe coded just to see what the AI could do on its own. Sometimes they're even useful because the AI figured out a way to do something that you were struggling with, so you get to take that concept back to production code.

Fritz

Can I also share some of Vibe Coded Server Panel I found for your references?

mikho

@Fritz said:
Can I also share some of Vibe Coded Server Panel I found for your references?

Sure, why not.

Fritz

@mikho said:

@Fritz said:
Can I also share some of Vibe Coded Server Panel I found for your references?

Sure, why not.

I'm not sure if this fits to your topic, but here you go:

https://github.com/BrowserlessAPI/VortexPanel

100% Vibe Coding.

mikho

@Fritz said:

@mikho said:

@Fritz said:
Can I also share some of Vibe Coded Server Panel I found for your references?

Sure, why not.

I'm not sure if this fits to your topic, but here you go:

https://github.com/BrowserlessAPI/VortexPanel

100% Vibe Coding.

Thanks!
I’m sure there are keywords in there that I can use when writing the prompts.
Don’t want to miss out on the security and features.