The SDK table listed the surfaces an extension consumes but not the ones it can
now contribute to, and deploys had been missing since it shipped. Adds all six
with one worked example each, plus the rule that ties them together: namespace
what you register, the panel owns the UI and normalises what you hand back.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Promoting between WordPress environments ran in the request thread: no
console, no log stream, no retry, and a progress bar the pipeline page had
to keep alive itself. It now runs as a registered deployment kind, so it
inherits the Deploy Console, live logs, retry and a row in Deploy Activity.
POST /promote returns 202 with a job_id instead of blocking, and the UI
opens the console with it.
PromotionJob is kept, not replaced. It carries pre_promotion_snapshot_id,
the rollback pointer, which is WordPress domain a generic DeploymentJob has
no business holding — so the deployment records which promotion rows it
produced instead. They are collected by id watermark rather than from the
service's return value, because promote_* only reports the job on success
and a failed promotion is exactly when someone needs the snapshot.
A full promotion runs two five-step halves and restarts its own numbering
at 1 for the second, so the progress bridge carries an offset across the
reset — otherwise the console's step strip walks backwards halfway through.
Two gaps this exposed in the SDK, both fixed here:
- Plugin kinds never closed their log stream, so they got no per-step
timings, no failure tail and no hint, and no terminal status push. The
handler and the runner also built separate streams, so the timings one
recorded were dropped by the other's close; they now share one per job.
- A handler that reported failure by return value logged nothing, leaving
a failed run with no reason visible in the console.
The console now titles a run from plan.title, so a contributed kind names
itself without a branch per kind in the frontend.
A locked environment is refused by the endpoint rather than by the job:
queueing first would send the user to a console that fails a second later.
The pipeline service still re-checks, since a lock can be taken in between.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- ThemeContext: fetch pre-auth panel default (/public/active) and follow it
until a user picks a skin; ThemeSync bridge loads installed themes after auth
- Theme Gallery admin actions: set panel default, remove installed themes
- Browse modal: install community themes from the registry (offline-tolerant)
- Import theme.json (admin, paste/upload)
- Theme Studio: grouped color editor over the LIVE panel, start-from any
installed theme, Export theme.json, Save-to-panel, and Submit = a prefilled
GitHub new-file PR against serverkit-themes
- docs/THEMING.md (token reference + rules + submit flow); README docs table +
ROADMAP "Recently Completed"
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Wire the server half of runtime-frontend delivery: get_active_contributions()
now emits panel sdk_version and a 'frontends' descriptor map {slug: {entry,
hashes, sdk_version}} for every active extension whose frontend_entry is a .mjs
ESM bundle. The bundle sha256 is pinned at install time into the plugin config
under the reserved _frontend_hashes key (no migration — reuses config_json);
update_plugin_config() and the config API preserve/hide reserved keys. Add the
extensions.runtime_frontend kill switch (default on). The client loader already
consumed this shape, so an installed extension's UI now renders on a pre-built
panel with no Vite rebuild. Un-skips the restored plan-25 recovery suites.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add docs/DEPLOY_CONSOLE.md (the feature + architecture), an architecture section
in docs/ARCHITECTURE.md, a CHANGELOG (Unreleased) entry, and move the Deploy
Console into the ROADMAP's Recently Completed list with its Active Development
checkboxes ticked.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The roadmap still said v1.6.0 / last-updated March 2026 while dev sits at
v1.7.52. Reframe the status note (actively developed, three tracks), refresh
Recently Completed with the actual 1.7.x highlights, add an Active Development
section (deploy console, extension platform, game server extensions, agent
streaming, release engineering), fix the milestones table incoherence, and
retitle the long-completed 'Upcoming Development' block.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Every planned core phase has shipped. New functionality now arrives as
installable extensions through the Marketplace, and core work is limited to
stability fixes and UI polish. Reframes the "what's next" list accordingly and
points feature requests at the extension SDK with an `extension-idea` label,
keeping the phase history as the record of how the core was built.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Four files were stored with CRLF in git while .gitattributes mandates
`* text=auto eol=lf`, so git reported them as perpetually "modified":
- ROADMAP.md
- backend/app/__init__.py
- backend/app/models/__init__.py
- frontend/src/App.jsx
One-time `git add --renormalize` rewriting the stored blobs to LF. Pure
line-ending change — `git diff --ignore-cr-at-eol` is empty, i.e. zero
content was altered. Windows scripts (*.ps1/*.bat/*.cmd) are untouched;
.gitattributes pins them to CRLF and they were correctly skipped.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Phase 37: Progressive Web App manifest, service worker for offline caching,
push notification registration, quick actions API, mobile summary endpoint,
and offline data caching for server status.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 36: Redis caching with in-memory fallback, cache decorator for
functions, background job queue with worker pool, job status tracking,
cache stats/flush endpoints, and job cleanup.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 35: DigitalOcean, Hetzner, Vultr, Linode integration, server creation
wizard (region/size/OS/SSH), auto agent install, cost tracking, snapshot
management, and destroy with confirmation safeguards.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 34: Public status pages, automated health checks (HTTP/TCP/DNS/ping),
component grouping, incident timeline, maintenance windows, uptime tracking
(24h/7d/30d/90d), status badges, and customizable branding.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Phase 32: DNS zone editor with A/AAAA/CNAME/MX/TXT/SRV/CAA records,
Cloudflare/Route53/DigitalOcean API sync, propagation checker, template
presets (web/email hosting), BIND zone import/export.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Adds cross-server Fleet Monitor endpoints and models, plus broad security and robustness improvements across agent, backend, and tooling.
Key changes:
- New fleet monitor API (endpoints for heatmap, comparison, alerts, thresholds, anomalies, forecast, search, exports, and Prometheus) and service skeleton.
- New DB models for ServerAlertThreshold and MetricAlert to support metric alerts.
- Agent discovery/registration hardening: HMAC-signed discovery requests, signature/timestamp validation, minimal discovery responses, HMAC-based unregister headers, and enforced command timeout cap in agent command handling.
- WebSocket and agent client TLS handling gated by SERVERKIT_INSECURE_TLS env var; added auth rate limiting on agent gateway.
- Docker-compose: parameterize agent image via AGENT_VERSION and avoid running as root by adding docker group access.
- Backend security & policy: tightened CSP script/style sources, request size limit, 2FA pending-token rejection on non-2FA endpoints, registration flow/guards, admin-only SSO admin routes via middleware, rate limits on sensitive endpoints, and logging for auth/2FA events.
- Database service hardening: identifier validation, avoid passing passwords on CLI (use env vars), safer subprocess usage, and docker exec handling improvements.
- CronService: command validation to prevent shell injection and run commands without shell=True; build_service and other subprocess usages updated similarly.
- Misc: .env.example notes clarified for encryption key generation, invitation token generation improved, agent registry timestamp window reduced, various logging and input validations added, frontend FleetMonitor page and styles stubbed in, and Vite/config/style updates.
Overall this commit implements fleet monitoring scaffolding and a set of security, validation, and operational improvements to make agent discovery, registration, command execution, and backend services safer and more robust.
Introduce a full workflow/automation subsystem: new WorkflowEngine with DAG validation/execution (Kahn's algorithm), logic-if branching, variable interpolation, script sandboxing (timeouts, output limits), retry semantics, notification nodes, and an in-process WorkflowEventBus for event-triggered workflows. Backend API updates include webhook trigger and validate endpoints, auto-generation of webhook IDs on create/update, and services emitting events (git push, health check failures, app stopped, monitoring alerts). Add Alembic migration to create workflow-related tables and bump VERSION to 1.4.0. Also update .gitignore, add GitHub issue/PR templates, quick-start script, and various frontend workflow panel/component adjustments to support the new automation features.
Introduce a full-featured workflow automation system: add WorkflowEngine service to execute workflows, background scheduler to trigger cron workflows, and croniter dependency. Extend Workflow model with automation fields (is_active, trigger_type, trigger_config, last_run_at, last_status) and add WorkflowExecution and WorkflowLog models. Add API endpoints to start executions, list executions, fetch execution details and logs, and persist execution records/logs. Implement frontend components for workflow nodes, config panels, and an execution history UI (multiple new React components) and wire minor builder UI imports. Note: database migrations are required to add new columns and tables.
Add user-configurable sidebar and initial workflow/environment features across backend, frontend, and docs.
Backend: store sidebar_config on User (JSON column), add get_sidebar_config / set_sidebar_config helpers, include sidebar_config in user.to_dict(), and validate/update sidebar_config in the update_current_user API (preset and hiddenItems validation).
Frontend: refactor Sidebar to compute visible items via a shared sidebarItems module and memoized grouping/rendering; add settings UI and sidebarItems (new components) and update settings styles to support sidebar configuration.
Docs & README: update README and ARCHITECTURE to document Workflow Builder, Environment Pipeline, and other new/renamed features; bump roadmap versions and reorder/expand roadmap phases to reflect Visual Designer, Automation Engine, pipeline, and monitoring work.
Overall: wires up end-to-end support for customizable sidebar preferences, surfaces them via API, and updates UI + documentation to reflect new automation and pipeline features.
Bump current development version to v1.5.0 and reorganize the roadmap to reflect completed work, reprioritize upcoming work, and add several new planned phases. Marked many items as completed (Team & Permissions, API Enhancements, SSO/OAuth, Database Migrations/Alembic, Multi-Server, Git Deployment, Advanced Security) and replaced older phase entries with new high-priority initiatives such as the New UI & Services page, Customizable Sidebar & Dashboard Views, Migration Wizard frontend, Container Logs & Monitoring UI, DNS management, Nginx advanced config, and expanded planned phases through v3.0. Also updated the version table to show completed and current releases and adjusted the contribution priority list to highlight UI, DNS, status page, and Nginx work. These changes keep the roadmap accurate with recent progress and surface critical next steps (notably merging the new-ui branch and migration UX).
Add full SSO (Google, GitHub, generic OIDC, SAML) support and integrate Alembic-based DB migrations. Introduces OAuthIdentity model, sso_service, SSO API blueprint (authorize/callback/link/unlink/admin/config/test), and settings to enable/configure providers and enforce SSO-only logins. Integrates Flask-Migrate and a MigrationService with API endpoints for status/backup/apply/history and includes Alembic scaffolding (migrations/versions/001_baseline.py). Update app init to register SSO and migrations blueprints and initialize Migrate; replace fragile auto-column hack with MigrationService.prepare/check. Update User model (nullable password_hash, auth_provider, has_password/to_dict fields), add AuditLog SSO actions, add frontend SSO components/pages and a migration UI, and update ROADMAP and requirements. Notes: token encryption uses Fernet derived from SECRET_KEY; migrations may add the new auth_provider column at startup.
Introduce a full email management feature: adds EmailService (Postfix/Dovecot/SpamAssassin/OpenDKIM management, account creation, forwarding, webmail, queue/logs, service control), new email API blueprint with admin-protected endpoints, and EmailAccount DB model. Register the email blueprint in app init. Frontend: add Email page, route and sidebar link, preload accent color + theme to prevent FOUC, new email styles and a dashboard layout hook. Also update ROADMAP.md to include Phase 21 SSO/OAuth and bump roadmap last-updated date.
Implements backend and frontend support for streaming Docker container logs from remote servers. Adds new API endpoints, agent handler, and UI controls for selecting log line count. Updates documentation to reflect the completed feature.
Implemented agent auto-update functionality, including periodic update checks, manual update command, and configuration options. Added backend API endpoints for agent version checking, update triggering, and download redirection. Updated documentation to reflect completion of the auto-update system.
Introduced Linux (install.sh) and Windows (install.ps1) installation scripts for ServerKit agent, and exposed new backend endpoints to serve these scripts and installation instructions. Added a GitHub Actions workflow (agent-release.yml) for automated agent builds and releases. Updated ROADMAP.md and SERVERS_INTEGRATION_PLAN.md to reflect progress on installation and distribution features.
Introduces the initial Go-based ServerKit agent implementation, supporting Docker and system metrics collection, with supporting scripts and documentation. Adds a comprehensive multi-server management integration plan, including architecture, security model, database schema, API design, frontend updates, installation methods, and phased implementation roadmap. Updates ROADMAP.md to mark advanced security phase as completed.
Moved firewall management UI from its own page into a new tab within the Security page for unified security management. Updated backend firewall service to improve detection of installed firewalls. Adjusted sidebar navigation and routing to remove the standalone Firewall page. Added new styles for the integrated firewall tab and updated roadmap to reflect these changes.
Introduces models and services for managing Git webhooks, deployment history, and Gitea repository interactions. Adds comprehensive API endpoints for webhook CRUD, repository browsing, deployment triggering, rollback, and log retrieval. Updates ROADMAP.md to remove version targets from planned features.
Introduces a production-ready Dockerfile, a comprehensive CONTRIBUTING.md, and new documentation files (API, installation, roadmap). Updates .env.example with improved comments and structure, enhances .gitignore, and refines the README with expanded features, requirements, and setup instructions. Roadmap and planning files are reorganized, and obsolete HTML is removed.
Add backend and frontend foundations for ServerKit, including Flask API structure, SQLAlchemy models, service layers, and React app with authentication context and service hooks. Implement core API endpoints for authentication, application management, Docker, databases, and system operations. Update README with project overview, tech stack, and setup instructions. Add development roadmap and example environment configuration.
