Developer self-service is the platform-engineering capability that lets product teams provision environments, databases, services, storage, and observability on their own — without filing tickets — typically in under an hour from request to running. It targets engineering organizations where the wait between “team needs an environment” and “team has one” stretches into days or weeks, decaying product velocity. Aenix builds this capability into platforms teams actually adopt: opinionated golden paths backed by a real platform layer, not a catalog UI as wallpaper. Engagements deliver a golden-path inventory of the ten most common requests, self-service paths designed and implemented by Aenix engineers, and an adoption-metrics framework. The work runs on the developer self-service layer of Ænix Private Cloud Platform, the company’s productized Internal Developer Platform built on Cozystack.
One of the most expensive things in most engineering organizations is the wait time between “team needs an environment” and “team has an environment.” When that gap is days or weeks, product velocity decays measurably; when it’s hours, the platform investment compounds for years.
Ænix builds developer self-service capability into platforms that product teams actually adopt — not Backstage as wallpaper, but underlying golden paths that provision what a team asks for without filing a ticket.
Pairs with: Ænix Private Cloud Platform and its developer self-service layer — GitLab automation, Argo CD workflows, self-service APIs, golden-path templates, engineering productivity dashboards. Free Platform Engineering Maturity Assessment →.
What developer self-service actually looks like
A useful working definition: developer self-service is when the most common 10 product-team needs can be satisfied without filing a ticket, completed in under an hour from request to running.
Product teamsEnvironmentDatabaseService
request without tickets
Ænix Private Cloud Platform — self-service layerGolden pathsSelf-service APIs
provisions on Cozystack
Provisioned servicesObject storageObservabilityCI/CD
in under an hour
Product velocityHours, not weeks
Common requests:
- New environment provisioning (dev / staging / preview)
- New service deployment (HTTP API, batch job, scheduled job)
- Database provisioning (managed PostgreSQL / MariaDB / Valkey)
- Object storage bucket
- Observability onboarding (metrics + logs + traces)
- Secrets management
- Network access to legacy or shared services
- Identity / SSO integration
- CI/CD pipeline setup
- Backup/DR for stateful workloads
If 7 of these 10 require tickets in your org — that’s where the engagement lives.
Where most “self-service” stops
- Catalog-only Backstage — registry exists, but actual provisioning still requires platform-team intervention.
- Half-self-service — three of the ten requests are self-service; seven aren’t.
- Self-service that broke — works for golden path; breaks at any deviation; product teams stop trusting it.
- Documentation as self-service — “you can do it yourself” pointing at runbook teams have to interpret manually.
The honest version requires opinionated platform underneath, not just a catalog UI.
How Ænix engages
Self-service is part of broader platform engineering work — see Internal Developer Platform services and Platform Engineering services for the engagement framing. The self-service-specific output is:
- Golden-path inventory — current state vs target for the 10 most-common requests
- Self-service paths designed — for the priority requests
- Implementation engagement — Ænix engineers build paths integrated with your platform
- Adoption metrics framework — measure what’s working
Engagement structure
| Phase | Duration |
|---|
| Discovery | 30 min, free |
| Assessment | 14-28 days (within Platform Readiness Assessment) |
| Build | 1-6 months |
Pricing
Assessment
On request
Build engagement
On request
How to start
Ænix is the team behind Cozystack (CNCF Project), and we offer Ænix Platform — our commercial productized offering based on Cozystack.
Frequently asked questions
What counts as real developer self-service versus a catalog?
Real self-service means the most common product-team requests are completed without filing a ticket, in under an hour from request to running. A catalog-only Backstage where provisioning still needs platform-team intervention does not qualify — that is a registry, not self-service.
Which requests should be self-service first?
Aenix scopes the ten most common needs: environment provisioning, service deployment, database provisioning (PostgreSQL, MariaDB, Valkey), object storage, observability onboarding, secrets management, network access, SSO integration, CI/CD setup, and backup/DR. The engagement prioritizes whichever of these still require tickets in your organization.
How does Aenix deliver developer self-service?
Through a golden-path inventory (current versus target state), self-service paths designed for priority requests, an implementation engagement where Aenix engineers build the paths into your platform, and an adoption-metrics framework to measure what works. It is scoped within broader Internal Developer Platform and Platform Engineering services.
What platform does the self-service capability run on?
The developer self-service layer of Ænix Private Cloud Platform — an internal-developer-platform layer with GitLab automation, Argo CD workflows, self-service APIs, golden-path templates, and engineering productivity dashboards. It is built on Cozystack, which runs VMs and containers on one Kubernetes API via KubeVirt, with Cilium eBPF networking and LINSTOR/DRBD storage.
How long before product teams can self-serve?
Discovery is a free 30-minute call. Assessment runs 14-28 days within a Platform Readiness Assessment. The build engagement spans 1-6 months depending on how many golden paths are in scope and the maturity of the existing platform.
Is there vendor lock-in?
No. The capability is built on Cozystack, an open-source CNCF project licensed under Apache 2.0 with no per-CPU or per-core licensing. The golden paths and platform layer use standard Kubernetes APIs, so the foundation remains portable.
