240 lines
5.7 KiB
Markdown
240 lines
5.7 KiB
Markdown
# Roadmap
|
|
|
|
## Goal
|
|
|
|
Build an MVP web panel for server management with a shared backend for future Telegram bot integration.
|
|
|
|
## Product Scope
|
|
|
|
The first version should let an authorized user:
|
|
|
|
- log in to the panel;
|
|
- see a list of servers;
|
|
- view basic server health and metrics;
|
|
- view managed services;
|
|
- start, stop, and restart allowed services;
|
|
- read recent logs;
|
|
- receive Telegram notifications;
|
|
- run a small set of Telegram bot commands with access control;
|
|
- review audit history for administrative actions.
|
|
|
|
## Guiding Principles
|
|
|
|
- Keep changes small and reviewable.
|
|
- Prefer safe, explicit operations over flexible but risky remote execution.
|
|
- Use one backend for both web UI and Telegram bot logic.
|
|
- Put all sensitive values in environment variables.
|
|
- Record all control actions in audit logs.
|
|
|
|
## Recommended Stack
|
|
|
|
- Backend: FastAPI
|
|
- Frontend: React + Vite
|
|
- Database: PostgreSQL
|
|
- Queue/background tasks: Redis + worker
|
|
- Bot: Python Telegram bot process
|
|
- Deployment: Docker Compose for dev and first-stage deployment
|
|
|
|
## Phase 0: Discovery and Design
|
|
|
|
### Outcome
|
|
|
|
Agree on MVP boundaries and technical constraints before implementation starts.
|
|
|
|
### Tasks
|
|
|
|
- confirm target servers and operating systems;
|
|
- define which services can be controlled from the panel;
|
|
- define user roles: `admin`, `operator`, `viewer`;
|
|
- decide whether server access uses SSH, Docker API, or local agent;
|
|
- define initial Telegram bot scope: notifications only or notifications plus commands;
|
|
- define minimal audit requirements;
|
|
- prepare environment variable list.
|
|
|
|
### Deliverables
|
|
|
|
- architecture draft;
|
|
- endpoint list;
|
|
- entity list;
|
|
- deployment assumptions.
|
|
|
|
## Phase 1: Project Foundation
|
|
|
|
### Outcome
|
|
|
|
Working repository structure with backend, frontend, shared configuration, and local startup flow.
|
|
|
|
### Tasks
|
|
|
|
- create project folder structure;
|
|
- add backend app bootstrap;
|
|
- add frontend app bootstrap;
|
|
- add Docker Compose for local development;
|
|
- add `.env.example`;
|
|
- configure logging and base settings;
|
|
- add base documentation for setup and run.
|
|
|
|
### Deliverables
|
|
|
|
- local development environment starts successfully;
|
|
- backend health endpoint responds;
|
|
- frontend opens a basic shell page.
|
|
|
|
## Phase 2: Authentication and Authorization
|
|
|
|
### Outcome
|
|
|
|
Users can sign in and access features according to role.
|
|
|
|
### Tasks
|
|
|
|
- implement user model;
|
|
- implement password-based login;
|
|
- add JWT access and refresh flow;
|
|
- add role-based access checks;
|
|
- protect administrative endpoints;
|
|
- add bootstrap flow for first admin user.
|
|
|
|
### Deliverables
|
|
|
|
- login page works;
|
|
- protected API endpoints require authentication;
|
|
- role restrictions are enforced.
|
|
|
|
## Phase 3: Server Registry and Health
|
|
|
|
### Outcome
|
|
|
|
Users can add servers and inspect their status.
|
|
|
|
### Tasks
|
|
|
|
- create server model and CRUD;
|
|
- store connection metadata safely;
|
|
- implement connectivity check;
|
|
- implement health endpoint;
|
|
- expose basic metrics: CPU, memory, disk, uptime;
|
|
- show server list and server details in UI.
|
|
|
|
### Deliverables
|
|
|
|
- server list page;
|
|
- server details page;
|
|
- working health and metrics calls.
|
|
|
|
## Phase 4: Service Management
|
|
|
|
### Outcome
|
|
|
|
Users can inspect and control approved services.
|
|
|
|
### Tasks
|
|
|
|
- define allowed service list per server;
|
|
- implement service status retrieval;
|
|
- implement `start`, `stop`, `restart` actions;
|
|
- route actions through background tasks;
|
|
- prevent arbitrary shell execution;
|
|
- return action status to UI.
|
|
|
|
### Deliverables
|
|
|
|
- services page;
|
|
- action buttons with result feedback;
|
|
- safe service control flow.
|
|
|
|
## Phase 5: Logs and Audit
|
|
|
|
### Outcome
|
|
|
|
Users can see recent logs and administrators can review action history.
|
|
|
|
### Tasks
|
|
|
|
- implement recent log retrieval for managed services;
|
|
- add pagination or line limits;
|
|
- create audit log model;
|
|
- record actor, target, action, time, and result;
|
|
- build audit list page.
|
|
|
|
### Deliverables
|
|
|
|
- logs view for a selected service;
|
|
- audit view for administrative actions.
|
|
|
|
## Phase 6: Telegram Integration
|
|
|
|
### Outcome
|
|
|
|
Telegram bot is connected to the same backend and supports notifications plus safe commands.
|
|
|
|
### Tasks
|
|
|
|
- create bot process;
|
|
- add bot token and webhook or polling configuration;
|
|
- implement user-chat linking;
|
|
- add notifications for action success or failure;
|
|
- implement safe commands such as `/status`, `/services`, `/restart`;
|
|
- enforce role checks and user linking;
|
|
- log bot-triggered actions in audit records.
|
|
|
|
### Deliverables
|
|
|
|
- bot can send test notification;
|
|
- linked users can query status;
|
|
- restricted commands honor permissions.
|
|
|
|
## Phase 7: Hardening and Release Prep
|
|
|
|
### Outcome
|
|
|
|
The MVP is stable enough for limited internal use.
|
|
|
|
### Tasks
|
|
|
|
- improve error handling;
|
|
- review secrets management;
|
|
- add request validation;
|
|
- add smoke tests for critical flows;
|
|
- document deployment and rollback steps;
|
|
- review logs for useful operational debugging;
|
|
- validate Docker Compose configuration.
|
|
|
|
### Deliverables
|
|
|
|
- deployment documentation;
|
|
- smoke-tested MVP build;
|
|
- known risks list.
|
|
|
|
## Suggested Timeline
|
|
|
|
## Week 1
|
|
|
|
- Day 1: project bootstrap and local environment
|
|
- Day 2: auth and roles
|
|
- Day 3: server CRUD and health
|
|
- Day 4: metrics and server UI
|
|
- Day 5: service management backend
|
|
|
|
## Week 2
|
|
|
|
- Day 6: service management UI
|
|
- Day 7: logs and audit
|
|
- Day 8: Telegram bot skeleton and linking
|
|
- Day 9: notifications and safe commands
|
|
- Day 10: testing, docs, and hardening
|
|
|
|
## MVP Exit Criteria
|
|
|
|
The MVP is complete when:
|
|
|
|
- an admin can log in;
|
|
- at least one server can be added;
|
|
- server health and metrics are visible;
|
|
- approved services can be restarted safely;
|
|
- recent logs can be viewed;
|
|
- all administrative actions are audited;
|
|
- Telegram notifications work;
|
|
- at least one Telegram command works with permissions;
|
|
- setup steps are documented.
|