Self-Service Platform Console
A developer-facing control plane that turns cloud and operational requests into policy-governed, auditable workflows across GitHub, Terraform Enterprise, Argo, and Google Cloud.
Problem
Platform consumers depended on tickets and manual handoffs to onboard applications, provision cloud resources, and complete routine operational work. Even standardized requests moved slowly because engineers had to interpret tickets, collect approvals, update repositories, watch automation, and report the result back to the requester.
The platform needed a self-service experience that made the paved road easy to use without weakening approval, security, or audit requirements.
What I built
I built a self-service platform console with a Next.js frontend and a Django control plane. It presents platform capabilities as reusable catalog workflows and guides consumers through the inputs, ownership details, and policy requirements for each request.
The catalog supports application onboarding and common operations such as provisioning Google Cloud Storage buckets, creating Kubernetes namespaces, issuing certificates, creating Secret Manager resources, and initiating other platform-owned workflows.
Architecture
- Next.js provides the catalog, request forms, workflow history, and live status experience.
- Django owns authentication, authorization, validation, policy evaluation, workflow state, and the API contract.
- PostgreSQL stores the durable execution record, state transitions, external references, audit history, and pending outbox events.
- Pub/Sub decouples workflow events from execution and allows each stage to be retried and scaled independently.
- Celery workers perform short, idempotent actions rather than holding long-running approval or review waits in memory.
- Execution adapters provide a common plan, execute, status, cancel, and reconcile contract across GitHub, Terraform Enterprise, Argo Workflows, and bounded Python automation.
Every transition carries one workflow identifier across PostgreSQL, Pub/Sub, Jira, GitHub, and the selected execution backend.
Durable workflow model
Each request advances through an explicit state machine: requested, validated, awaiting approval, approved, change proposed, awaiting review, executing, and succeeded or failed. PostgreSQL is the orchestration record, while Jira, GitHub, Terraform Enterprise, Argo, and Google Cloud remain authoritative for the objects they own.
A transactional outbox records state changes and outbound events in the same database transaction. A publisher forwards those events to Pub/Sub, and consumers use workflow and operation identifiers to handle duplicate delivery safely.
Approval and change flow
- The control plane validates ownership, permissions, required metadata, quota, and policy before accepting work.
- Standard, pre-approved changes can pass the policy gate automatically. Jira still provides a visible audit record where required.
- Elevated changes wait for an authorized Jira approval. Approval events resume the workflow immediately, with scheduled reconciliation as protection against missed events or external outages.
- For repository-backed workflows, the platform-console GitHub App creates a pull request in the appropriate repository and attaches the workflow identifier and evidence.
- Required CI, policy, and security checks must pass before merge. Standard changes can merge automatically; elevated changes wait for the required GitHub reviewers.
- The selected execution adapter starts a Terraform Enterprise run, Argo Workflow, Git-based delivery process, or idempotent Python operation.
- Status events and reconciliation jobs update the console, notify the requester, preserve the audit trail, and close Jira when the requested outcome is complete.
Reliability and security
- Idempotency keys prevent duplicate requests and repeated events from provisioning the same resource twice.
- Optimistic state transitions and resource-level locking protect against concurrent workflows changing the same target.
- Retries use bounded exponential backoff, and exhausted events move to a dead-letter path for operator recovery.
- Reconciliation detects stalled work and repairs drift between the console and external systems.
- GitHub App tokens and workload identity replace broad, long-lived credentials.
- Least-privilege service accounts, separation of requester and approver, immutable audit events, ownership labels, and policy checks protect privileged workflows.
- Secret values are never returned through the console; it provisions and governs Secret Manager resources and their access paths.
Design tradeoffs
Keeping Jira and GitHub in the workflow adds external dependencies, but it preserves familiar approval and change-management controls. The adapter model adds an interface to maintain, but prevents backend-specific behavior from spreading throughout the product. PostgreSQL and the outbox add orchestration discipline while allowing Celery and Pub/Sub to remain simple, scalable execution components.
Impact
The console replaced repeated ticket interpretation and platform-team handoffs with a consistent, observable paved road. For pre-approved requests, automated validation, change creation, policy checks, execution, and notification shortened average fulfillment time by approximately 60% while improving traceability for consumers, operators, and auditors.