highperfocused/agent
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Build multi-tenant control plane (separate Vite app) with Docker Swarm agent orchestration #5

New Issue
Open
opened 2026-03-12 21:53:51 +01:00 by highperfocused · 0 comments
highperfocused commented 2026-03-12 21:53:51 +01:00
Owner
Copy Link

Context

The current gateway includes a minimal built-in web UI for testing, but we need a dedicated product UI and backend flow for a multi-tenant agent platform.

A standalone Vite project is now scaffolded in platform-ui/ (kept separate from backend runtime image).

Goal

Allow users to:

  1. register/login,
  2. create/join a tenant workspace,
  3. spawn and manage agent services via Docker Swarm,
  4. observe lifecycle + usage per tenant.

Scope

  • Tenant identity + authentication (email/password or SSO-ready abstraction)
  • Tenant-scoped authorization (RBAC)
  • Agent service creation workflow (image, env, replicas, limits)
  • Docker Swarm integration layer (create/update/scale/restart/remove services)
  • Tenant isolation strategy (labels, networks, secrets, naming conventions)
  • Service status + event stream in UI
  • Audit logs (who spawned/stopped what, and when)
  • Quotas/guardrails per tenant (max agents/replicas/resources)

Frontend deliverables (platform-ui/)

  • Auth pages (register/login)
  • Tenant switcher + organization settings
  • Agent creation wizard
  • Agent list/details view with status and actions
  • Error states, retries, and optimistic updates

Backend deliverables

  • API endpoints for tenants/users/agents
  • Swarm orchestration service with structured logging
  • Health model for agent service state
  • Permission checks on every tenant-scoped endpoint

Acceptance criteria

  • A new user can register and create a tenant
  • A tenant admin can spawn an agent service on Swarm
  • Agent status transitions are visible in UI (pending -> running/failed)
  • Tenant A cannot view or mutate Tenant B resources
  • All lifecycle actions are audit logged

Notes

  • platform-ui/ must stay a separate project.
  • It should not be included in backend Docker runtime images (already enforced by Dockerfile copy scope + .dockerignore).
## Context The current gateway includes a minimal built-in web UI for testing, but we need a dedicated product UI and backend flow for a **multi-tenant agent platform**. A standalone Vite project is now scaffolded in `platform-ui/` (kept separate from backend runtime image). ## Goal Allow users to: 1. register/login, 2. create/join a tenant workspace, 3. spawn and manage agent services via Docker Swarm, 4. observe lifecycle + usage per tenant. ## Scope - [ ] Tenant identity + authentication (email/password or SSO-ready abstraction) - [ ] Tenant-scoped authorization (RBAC) - [ ] Agent service creation workflow (`image`, `env`, `replicas`, `limits`) - [ ] Docker Swarm integration layer (create/update/scale/restart/remove services) - [ ] Tenant isolation strategy (labels, networks, secrets, naming conventions) - [ ] Service status + event stream in UI - [ ] Audit logs (who spawned/stopped what, and when) - [ ] Quotas/guardrails per tenant (max agents/replicas/resources) ## Frontend deliverables (`platform-ui/`) - [ ] Auth pages (register/login) - [ ] Tenant switcher + organization settings - [ ] Agent creation wizard - [ ] Agent list/details view with status and actions - [ ] Error states, retries, and optimistic updates ## Backend deliverables - [ ] API endpoints for tenants/users/agents - [ ] Swarm orchestration service with structured logging - [ ] Health model for agent service state - [ ] Permission checks on every tenant-scoped endpoint ## Acceptance criteria - [ ] A new user can register and create a tenant - [ ] A tenant admin can spawn an agent service on Swarm - [ ] Agent status transitions are visible in UI (pending -> running/failed) - [ ] Tenant A cannot view or mutate Tenant B resources - [ ] All lifecycle actions are audit logged ## Notes - `platform-ui/` must stay a separate project. - It should not be included in backend Docker runtime images (already enforced by Dockerfile copy scope + `.dockerignore`).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
highperfocused
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: highperfocused/agent#5
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?