Self-hosted platform for standing up and running software factories on AWS: complete DevSecOps environments with secure delivery pipelines, supply-chain controls, compliance evidence and multi-tenant governance — in minutes, not months.
Why Pipeline Builder exists, and what an engineering organization gets from it.
error or critical severity, so scanning is mandatory rather than opt-in.This page is written for engineering leaders, platform teams and developers evaluating or adopting the platform. It covers the CI/CD problems it targets, the six ways it addresses them, and the organization → team → billing model that ties tenancy, quota pooling and subscription tiers together.
If you want the full caps model rather than the rationale, skip to Organizations, Teams & Billing. If you want to see it working, Getting started is three commands.
Most organizations struggle with the same CI/CD challenges as they scale:
Six mechanisms, each aimed at one of those problems.
Developers create production-ready pipelines without writing CDK, CloudFormation or buildspec files.
| Interface | Use case |
|---|---|
| Dashboard | Visual builder — select plugins, configure stages, deploy |
| AI prompt | Paste a Git URL, get a complete pipeline generated from repo analysis |
| CLI | pipeline-manager pipeline create for scripted workflows |
| REST API | Programmatic control for platform teams |
| CDK construct | PipelineBuilder for infrastructure-as-code |
A Java team gets build, test, lint, security scan and deploy stages in minutes — not days.
119 pre-built, containerized plugins covering the full CI/CD lifecycle:
| Category | What it covers |
|---|---|
| Language (11) | Java (Corretto/Oracle), Python, Node.js, Go, Rust, .NET, C++, PHP, Ruby |
| Security (34) | Snyk, SonarCloud, Trivy, Semgrep, Veracode, Checkmarx, Fortify |
| Quality (17) | ESLint, Prettier, Checkstyle, Clippy, Ruff, ShellCheck |
| Testing (14) | Jest, Pytest, Cypress, Playwright, k6, Postman, Artillery |
| Artifact (16) | Docker, ECR, GHCR, npm, PyPI, Maven, NuGet, Cargo |
| Deploy (13) | Terraform, CloudFormation, Kubernetes, Helm, Pulumi, ECS, Lambda |
| Notification (5) | Slack, Microsoft Teams, email, PagerDuty, GitHub status |
| Infrastructure (5) | CDK synth, S3 cache, manual approval, shell |
| Monitoring (3) | Datadog, New Relic, Sentry |
| AI (1) | Multi-provider Dockerfile generation |
Every plugin is versioned, tested and shared across the organization. Teams use the same tools instead of maintaining their own Docker images and build scripts.
The compliance engine validates every pipeline and plugin before creation, not after deployment.
How it works:
all / any mode), and specific plugins or pipelines can be granted scoped exemptions with an audit trail.error or critical severity block creation (HTTP 403).warning severity log and allow.What that means for the organization:
Every resource is scoped to an organization with role-based access control:
| Resource | Isolation |
|---|---|
| Pipelines | Scoped to (project, organization, orgId) |
| Plugins | Scoped by orgId + visibility (private/org/public) |
| Secrets | AWS Secrets Manager path: {prefix}/{orgId}/{secretName} |
| Quotas | Per-org limits on plugins, pipelines, API calls, AI calls, storage, and more |
| Compliance | Per-org rules and policies |
| Billing | Per-org subscription tiers and usage tracking |
Teams can’t see or modify each other’s resources. Public plugins are shared; private plugins are org-only. Organizations can also nest teams that share one account and pool their quotas — see Organizations, Teams & Billing.
Pipelines deploy as native AWS CodePipeline + CodeBuild in the customer’s own AWS account.
EventBridge captures every CodePipeline and CodeBuild state change. Reports include:
git clone <repo-url> pipeline-builder && cd pipeline-builder
pnpm install && pnpm build
cd deploy/local/docker && chmod +x bin/setup.sh && ./bin/setup.sh
setup.sh.https://localhost:8443 — register, create an org, and start building pipelines.For a real deployment rather than an evaluation, see AWS Deployment; for the full first-admin flow, Onboarding.
Every resource lives inside an organization, organizations can optionally nest teams, and each account carries a billing subscription that sets its caps. The three work together: the organization is the boundary, teams share a boundary’s resources under one account, and billing decides how much that account can do.
An organization is a self-contained, isolated workspace — your company, a business unit, or a single squad. It is the tenancy boundary: every pipeline, plugin, compliance rule, quota, secret, subscription and analytics record belongs to exactly one organization, and organizations cannot see or modify each other’s resources. A user can belong to several organizations and acts within one at a time, switching with the org switcher.
Roles (RBAC), enforced at the API layer:
| Built-in Role (seeded permission bundle) | What its permissions cover |
|---|---|
| Owner | Full control — manage members, transfer ownership, delete the organization (exactly one owner per org) |
| Admin | Manage plugins, pipelines, compliance rules and quotas; invite and manage members |
| Member | Create and manage their own pipelines and plugins |
The coarse owner / admin / member label on a membership is for display and ownership transfer only — it grants nothing. Permissions come only from the Roles assigned to a user (Permissions).
Access is granted through Roles, each a named set of fine-grained resource:action permissions. A user’s effective permissions are the union of the Roles assigned to them; there is no separate role-based baseline. New orgs seed default Roles (Admin, Member); the system org also gets Super Admin; a platform Super Admin implicitly holds every permission. Admins with roles:manage can author custom Roles, bounded by their own permissions — a permission ceiling.
Scoped to the org: pipelines (by project + orgId), plugins (by orgId + the visibility ladder: private / org / public), compliance rules and exemptions, quotas and seats, secrets (pipeline-builder/{orgId}/{secretName}), the billing subscription, and execution analytics.
The shared system organization publishes a recommended plugin catalog and compliance-rule catalog that any organization can pull from or subscribe to — a common baseline without giving up isolation.
Membership is per-organization. Inviting a user into one org grants no access to another.
A team is an organization nested one level under a parent (root) organization. Nesting is opt-in: by default every organization is a flat, top-level root with no teams. A team is a full organization — its own members, roles and secrets — but it shares its parent’s account, so the parent can govern it and quotas, billing, visibility, compliance and analytics roll across the parent ↔ team relationship.
Each account — the root organization — carries a subscription tier that sets its baseline capabilities and caps, and can stack add-on bundles to raise specific caps or unlock features without changing tier. Teams don’t have separate bills: they share the root account’s subscription, and the effective limits are pooled across them.
Tiers — Developer, Pro, Team and Enterprise. Higher tiers raise every cap and unlock gated features.
| Developer | Pro | Team | Enterprise | |
|---|---|---|---|---|
| Price / month | $0 | $39 | $79 | $599 |
| Plugins | 25 | 50 | 75 | 150 |
| Pipelines | 2 | 5 | 6 | 30 |
| Member seats | 1 | 1 | 3 | 15 |
| API calls / period | 25,000 | 250,000 | 500,000 | 900,000 |
| AI calls / period | 25 | 1,000 | 2,500 | 9,000 |
| Registry storage | 2 GB | 25 GB | 60 GB | 250 GB |
| Dashboards | 20 | 200 | unlimited | unlimited |
| Alert rules / destinations | 50 / 10 | 500 / 50 | unlimited | unlimited |
| IdP configs | 1 | 5 | 5 | unlimited |
| AI generation (pipelines & plugins) | — | ✅ | ✅ | ✅ |
| Bulk operations | — | ✅ | ✅ | ✅ |
| Audit log | — | — | ✅ | ✅ |
| SSO | — | — | ✅ | ✅ |
| Custom integrations | — | — | — | ✅ |
| Teams (org → team nesting) | — | — | ✅ | ✅ |
| Priority support | — | ✅ | ✅ | ✅ |
AI quotas are sized smaller than API quotas because AI calls carry an external per-call dollar cost. -1 in the code means unlimited. System-org users always have every feature. Every limit and price is env-overridable (QUOTA_TIER_<TIER>_<LIMIT>, BILLING_PLAN_<TIER>_MONTHLY).
Unlimited tier. Beyond the four subscription tiers there is an Unlimited tier where every quota above is -1 and every gated feature is on. It exists for billing-disabled deployments: when BILLING_ENABLED=false there is nothing to meter or sell, so newly created orgs default to Unlimited and run everything uncapped. When billing is enabled, Unlimited is a valid stored tier but is never displayed, selectable or purchasable — it is excluded from the plans list and every tier picker, so only Developer/Pro/Team/Enterprise are ever offered.
Add-on bundles — stackable packs that adjust one dimension: per-Seat (with volume discounts, Team+), Pipeline Pack (+5, Team+), Plugin Pack (+25), API Pack (+100k calls), AI Pack (+2,500 calls), Storage Pack (+10 GB), Listing Pack (+10 plugin-ecosystem listings), plus the Scale Bundle combo and the feature bundles (Advanced Reporting, Team Usage Analytics, Standard/Advanced Compliance). SSO is not an add-on — it comes with the Team tier and up.
Effective limit = tier base + Σ(bundle grant × quantity), and the result pools across the account’s teams. This lets an account that needs a little more headroom buy the pack instead of jumping a whole tier. See Billing Add-on Bundles for the full catalog, prices and pooling rules.
Enforcement. Billing computes the effective entitlement and syncs it to the enforcing services — quota limits to the quota service, seats and purchased features to the platform service — always against the account root. Removing a bundle can’t drop a cap below current pooled usage.
Before: Spend days configuring CI/CD. Copy buildspecs from other repos. Debug IAM permissions. Manage Docker images for build tools.
After: Select plugins from a catalog. Deploy from the dashboard or CLI. Focus on application code, not infrastructure.
Before: Maintain shared CI/CD templates. Handle template drift across teams. Respond to “my pipeline broke” tickets.
After: Manage the plugin catalog. Define compliance rules. Monitor execution analytics. The platform enforces standards automatically.
Before: Audit pipelines manually. Chase teams to add scanners. Discover gaps after incidents.
After: Define compliance rules that mandate security scanning. Every pipeline is checked at creation time. The audit trail provides evidence for compliance reviews.
Before: No visibility into CI/CD health, costs or adoption. Can’t answer “are we secure?” with data.
After: Dashboards show pipeline health across the organization. Per-org billing tracks subscription and usage. Compliance reports prove security posture.
| Target | Best for | Infrastructure |
|---|---|---|
| Local (Docker Compose) | Development, demos | Single machine, all services in containers |
| Minikube (K8s) | Testing, small teams | Single node Kubernetes, KEDA auto-scaling |
| EC2 (Minikube on EC2) | Small-medium production | m5.4xlarge default (see InstanceType), persistent storage, Let’s Encrypt |
| EKS (Auto Mode) | Large-scale production | Managed Kubernetes, Karpenter autoscaling, EBS/EFS-backed PostgreSQL/MongoDB/Redis |
All deployment targets run the same services with the same configuration — .env files and K8s manifests are consistent across targets.
| Metric | Without Pipeline Builder | With Pipeline Builder |
|---|---|---|
| Time to first pipeline | 2–5 days | 5–15 minutes |
| Pipelines with security scanning | ~30% (opt-in) | 100% (enforced) |
| Unique CI/CD configurations | N (one per team) | 1 (shared plugin catalog) |
| Docker images to maintain | N (per team) | 0 (pre-built plugins) |
| AWS expertise required | Deep (CDK/CFN/IAM) | None (dashboard/CLI) |
| Visibility into CI/CD health | Manual/none | Real-time dashboards |
| Vendor lock-in | Yes (SaaS CI/CD) | None (native AWS resources) |