Introduction

IDP Next is an Internal Developer Platform (IDP): a single place where your engineering organization can see everything it runs (the Software Catalog) and do everything it needs (Self-Service workflows) — with governance built in.

What you get

Capability	What it means
Software Catalog	Services, repositories, teams, cloud resources and deployments modeled as entities, kept in sync automatically from GitHub, GitLab, GCP and AWS
Self-Service	Developers trigger real deployments and releases from a form — the platform orchestrates GitHub Actions and GitLab CI pipelines behind the scenes
Dashboards	Widgets over your catalog data: deployment frequency, services by language, PR status and more
Governance	RBAC roles, approval gates, encrypted secrets, service accounts and a full audit trail

What you'll build with this guide

This documentation is a hands-on tutorial. Following it end to end, you will set up a new organization that looks exactly like the live demo at idpnext.wazyneo.com:

1. Connect your tools — a GitHub App for pipeline orchestration, plus scheduled catalog ingestion from GitHub, GitLab, GCP and AWS using Ocean.
2. Model your catalog — blueprints for services and deployments, and catalog pages to browse them.
3. Wire your CI pipelines — add a deploy.yml GitHub Actions workflow and a .gitlab-ci.yml deploy job to your repositories, with status callbacks to the IDP.
4. Build self-service workflows — multi-step workflows that chain those pipelines together, including an approval-gated full-stack release.
5. Use the platform — run deployments from the Self-Service portal, track runs live, and browse the results in the catalog.

Every configuration file, pipeline, and JSON definition shown in these pages is the actual working configuration from the demo environment — you can copy it as-is and adapt names to your own organization.

Core concepts

• Organization — the top-level workspace. Users belong to an organization with roles.
• Tenant — an environment inside an organization (e.g. default, production). Blueprints and entities are scoped to a tenant.
• Blueprint — a schema that defines a type of catalog entity (Service, Deployment, Repository…).
• Entity — an instance of a blueprint (e.g. the orders-service repository).
• Data source — an external system (GitHub, GitLab, GCP, AWS) that syncs entities into the catalog.
• Workflow — a multi-step self-service operation (deploy, release…) with steps like GitHub Actions run, GitLab pipeline, Approval, and Upsert entity.
• Run — one execution of a workflow, with live step status and logs.

Ready? Log in and take a first tour →