-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Summary
DevOps OS currently functions as an automation and scaffolding tool for generating DevOps templates (CI/CD, Kubernetes, DevContainer, SRE configs, etc.).
This feature proposes adding an Internal Developer Platform (IDP) layer on top of the existing CLI and MCP capabilities to evolve DevOps OS into a self-service platform engineering system.
Important : This is an epic issue and there will be sub-issues create for completing the overall epic.
Motivation
DevOps OS already provides strong foundational capabilities for:
- DevOps automation
- Template generation
- Process-first DevOps adoption
- CLI-driven scaffolding
- MCP-based AI integration
However, modern platform engineering requires:
- Self-service workflows for developers
- Standardized platform abstractions
- Reduced cognitive load
- Discoverability of platform capabilities
Currently, users must interact via CLI commands. While powerful, this limits accessibility for:
- developers unfamiliar with DevOps
- teams needing centralized platform workflows
- organizations adopting platform engineering practices
To evolve DevOps OS into a true IDP (Internal Developer Platform), we need:
- a UI/UX layer
- a self-service interface
- a platform abstraction over existing generators
Proposed Solution
Introduce an IDP layer consisting of:
1. Backend (Platform API Layer)
Extend the existing MCP/FastAPI server into a platform service layer:
-
expose endpoints for:
- project creation
- service scaffolding
- CI/CD generation
- Kubernetes deployment configs
-
support a declarative config model (e.g.,
devopsos.yaml) -
integrate existing generators as reusable services
2. Web UI / Developer Portal
Build a lightweight developer portal:
Core features:
-
Create new project/service via UI
-
Select:
- language (Python, Go, Node, etc.)
- CI/CD provider
- deployment strategy (ArgoCD, Flux)
- observability stack
-
Trigger DevOps OS generators
-
View generated artifacts
-
Download or push to Git repository
3. Self-Service Workflows
Enable workflows like:
- “Create a new API service”
- “Bootstrap DevOps for existing repo”
- “Generate CI/CD + Kubernetes + DevContainer”
This can internally map to:
devopsos init
devopsos scaffold gha
devopsos scaffold argocd
devopsos scaffold sre4. Platform Abstraction Layer
Introduce a declarative config:
project:
name: sample-app
runtime:
language: python
pipeline:
provider: github-actions
deployment:
method: argocd
observability:
prometheus: trueThen:
devopsos generateUI can generate and manage this config.
5. Optional Enhancements (Future Scope)
- multi-project management
- Git integration (auto commit/push)
- architecture visualization
- plugin system integration
- AI-assisted DevOps workflows via MCP
Alternatives Considered
1. CLI-Only Approach
Continue enhancing CLI capabilities without adding UI.
Limitations:
- not accessible to non-DevOps users
- harder adoption in enterprise environments
- limited discoverability of features
2. Documentation-Driven Adoption
Rely on documentation and examples instead of UI.
Limitations:
- still requires high cognitive load
- does not provide self-service experience
- not aligned with platform engineering best practices
3. Integrate with Existing Platforms (e.g., Backstage)
Instead of building UI, integrate DevOps OS into an existing IDP like Backstage.
Limitations:
- reduces independence of DevOps OS
- adds external dependency
- limits control over user experience
Additional Context
This feature aligns with the long-term vision of DevOps OS as a:
- Process-First DevOps Platform
- Platform Engineering toolkit for small to mid-sized teams
- AI-native DevOps automation system
Reference direction:
- Backstage (developer portal)
- Humanitec (platform abstraction)
- Gitpod / Codespaces (dev environments)
The IDP layer would not replace CLI, but complement it:
CLI → power users
UI → self-service developers
API/MCP → AI integrations
This creates a unified platform experience.
Checklist
- I have searched for existing issues / feature requests before opening this one
- I am willing to contribute a PR to implement this feature
- I understand that a maintainer will review and assign this issue before work begins