Skip to content
Baru: lihat kecocokanmu dan dapatkan penawaran yang disesuaikan dalam hitungan menit.Coba estimator
Menu
Minta demoMasuk

Use case · Self-service onboarding

Developer membuat service tanpa mengajukan tiket.

Service baru tidak seharusnya menunggu di antrean. Dengan golden-path scaffolding, developer memilih template, mengisi formulir singkat, dan mendapatkan repo, pipeline, serta environment yang sudah tersambung dalam satu langkah. Policy guardrail menjaga setiap service itu tetap di dalam standar kamu, jadi self-service bukan berarti bebas tanpa aturan. Tim platform kamu menulis path-nya sekali dan berhenti membangun ulang setup yang sama secara manual.

Minta demoBaca dokumentasi

Who this is for

Platform or developer-experience engineer
Responsible for cutting ticket-driven toil without creating ungoverned sprawl, and needs golden paths that enforce baseline controls rather than just documenting them.
Application developer
Wants to start building on day one without waiting for an ops or security ticket to provision a repo, pipeline, and deploy target.
Security or compliance lead
Needs every new service to carry required controls from its first commit, not as a retrofit audit six months later.

Biaya dari ticket-ops

Onboarding lewat tiket memperlambat semua orang.

Ketika membuat service berarti mengajukan tiket, tim platform menjadi gerbang untuk pekerjaan rutin dan pekerjaan itu sendiri bergeser keluar dari standar. Orang yang seharusnya bisa meningkatkan platform malah menghabiskan harinya untuk menyediakannya secara manual.

  • Antrean adalah bottleneck-nya

    Service baru harus menunggu platform engineer yang sudah tenggelam di tiga tiket. Pekerjaannya kecil, tapi tunggunya tidak.

  • Setiap permintaan dikerjakan dari nol

    Tidak ada dua tiket yang mendeskripsikan setup dengan cara yang sama, jadi tim platform membangun ulang hal yang sama dengan sedikit perbedaan setiap kali.

  • Standar bergeser

    Environment yang dibangun manual melewatkan satu control di sini, satu tag di sana. Enam bulan kemudian, tidak ada dua service yang serupa dan tidak ada yang bisa menjelaskan kenapa.

Golden-path scaffolding

Satu formulir. Repo, pipeline, dan environment.

Golden path adalah template yang dimiliki tim platform kamu. Developer memilih salah satunya, mengisi formulir singkat, dan IntegraCI menyediakan service secara menyeluruh: repo sumber, build pipeline, dan target environment, semuanya terdaftar di katalog.

  1. Pilih golden path

    Mulai dari template yang dimiliki tim platform kamu: sebuah service, worker, atau frontend. Scaffold-nya membawa standar kamu, bukan repo kosong.

  2. Isi formulirnya

    Beri nama, tentukan owner, pilih target environment. Tidak perlu menulis YAML manual, tidak perlu mengajukan tiket infrastruktur.

  3. Dapatkan service yang sudah tersambung

    IntegraCI menyediakan repo, pipeline, dan environment sekaligus, terdaftar di katalog dan siap dirilis.

Service barugolden path

name

payments-api

owner

team-payments

environment

staging

  • repo dibuatgit
  • pipeline tersambungci
  • env tersediastaging
  • terkatalogowner diatur

tersedia dalam satu langkah

Brownfield juga

Mulai dari apa yang sudah kamu jalankan.

Onboarding bukan hanya untuk service baru. IntegraCI menemukan aplikasi yang sudah berjalan di host kamu dan mendeteksi stack dari repository mana pun, lalu mengusulkan onboard sekali klik. Kamu membawa aset yang sudah ada ke dalam path tanpa mendaftarkannya ulang secara manual.

Temukan aplikasi yang berjalan

IntegraCI menampilkan aplikasi yang sudah berjalan di host kamu ke dalam review inbox. Setujui satu dan aplikasi itu diimpor apa adanya, tanpa provisioning ulang workload yang sedang berjalan.

Deteksi stack sebuah repository

Arahkan ke sebuah repository dan IntegraCI mendeteksi bahasa serta framework-nya, menyarankan golden path, dan membuat service-nya untuk kamu.

Lihat service discovery

Guardrail sebagai policy

Self-service yang tetap memenuhi standar kamu.

Membuka provisioning untuk developer hanya berhasil jika guardrail-nya kuat. IntegraCI menaruh aturan di dalam policy, bukan di inbox reviewer: apa yang boleh dibuat dan di mana ditentukan oleh kode yang dimiliki tim platform kamu, dengan persetujuan manusia disisakan untuk langkah yang memang benar-benar memerlukannya.

  • Policy yang memutuskan, bukan antrean

    Apa yang boleh dibuat developer, dan di mana, diatur oleh policy yang kamu tulis sekali. Self-service tetap di dalam batas tanpa gerbang manusia di setiap permintaan.

  • Langkah berisiko berhenti untuk persetujuan manusia

    Sebagian besar aksi selesai dengan sendirinya. Yang membutuhkan persetujuan berhenti di approval inbox, jadi kecepatan tidak pernah mengorbankan pengawasan.

  • Standar tertanam di dalam template

    Scan, tag, kepemilikan, dan konfigurasi environment ikut dalam scaffold. Setiap service baru langsung patuh, bukan diperbaiki belakangan.

  • Terisolasi per tenant sejak hari pertama

    Service dan secret tiap tim berada di ruangnya sendiri, ditegakkan di bawah aplikasi oleh row-level security database. Baru bukan berarti bocor.

Apa yang berubah

Lebih cepat untuk developer, lebih tenang untuk tim platform.

  • Rilis di hari yang sama, bukan sprint yang sama

    Developer berpindah dari ide ke service yang berjalan dan terkatalog tanpa mengajukan tiket atau menunggu antrean platform.

  • Tim platform mendapatkan waktunya kembali

    Provisioning yang berulang pindah ke golden paths. Engineer menghabiskan waktunya untuk path itu sendiri, bukan untuk setup satuan.

  • Konsistensi yang bisa kamu audit

    Karena setiap service dimulai dari template ter-governance yang sama, katalog tetap seragam dan jejak audit mencatat siapa membuat apa.

The proof

Mechanisms you can point at, not adjectives.

The claim holds because of how it is built. Each control runs in the path, records what it did, and maps to the framework you report against.

Per-tier policy gate at scaffold time

Before the scaffold workflow completes, a policy-as-code check evaluates every required field for the service's tier: owner, classification, scanner configuration, and deploy target. The gate is fail-closed. If any required control is absent, the workflow halts and the developer sees the specific gap rather than a generic error. Each evaluation writes a dated entry to the tamper-evident audit trail, recording which policy version ran and whether it passed or failed.

Database-enforced row-level security from the first write

The moment a service record is created, database-enforced row-level security binds it to the provisioning tenant. No query issued from another tenant's session can read or modify that record, and this boundary is set at the data layer rather than in application code. The service's initial access scope is captured in the audit record and cannot be widened without a logged policy change.

Durable, auditable approval for state-changing provisioning steps

When onboarding requires assigning a deploy target or injecting credentials from the dedicated secrets store, the durable workflow pauses and routes an approval request to a designated reviewer. The reviewer's decision (approve or reject) is written to the tamper-evident audit trail with a timestamp and identity before the workflow continues. Any AI-assisted suggestions in the onboarding flow are advisory only; a person confirms every state-changing action.

Maps to

  • SOC 2
  • ISO 27001
  • NIST SSDF
  • CIS Controls

The platform maps your controls to these frameworks. The mapping helps you demonstrate them; it is not a certification.

The artifact is the proof

Service onboarding evidence record

An exportable record that captures the scaffold template version used, the policy checks that ran and passed at provisioning time, all human approvals collected, and the service's initial scorecard baseline, giving auditors a point-in-time proof that controls were in place from the service's first day.

Under the hood

The capabilities behind it

This job is not a separate product. It is the platform seen from one angle. Here are the capabilities it runs on.

Govern

Onboarding Guardrails

Mandatory or optional controls per tier, enforced everywhere

Quality

Scorecards

A running read on every service across the standards that matter

Deliver

Internal Developer Portal

A catalog with owners, scorecards, and golden paths

Govern

Policy as Code

Write governance rules as versioned, tested code

Deliver

Configuration & Secrets

Scoped config and secrets, masked and governed

Deliver

Continuous Integration

Govern the CI you already run with policy as code

Questions, answered.

Our developers already use template repositories and scripts for new services. How is this different?

Templates on their own document intent but cannot enforce it. IntegraCI wraps your golden path in a durable workflow that runs policy-as-code checks before the scaffold completes, assigns an owner in the catalog, wires the CI pipeline, and records the entire sequence in a tamper-evident audit trail. A developer using a bare template can skip any step; a developer going through IntegraCI cannot complete onboarding if a required control is missing.

What stops a developer from creating a repo directly in our SCM and bypassing the onboarding flow entirely?

Your SCM connector continuously monitors for repositories that are not registered in the catalog. Unregistered services surface as findings in the posture dashboard, so the gap is visible rather than silent. You can also configure the policy gate to block deployments from services that have not completed onboarding, which removes the practical incentive to go around the flow.

We have hundreds of existing services that predate any platform tooling. Do they all need to be re-onboarded?

No. Existing services are imported into the catalog through your SCM and CI connectors without re-running the scaffold. Their scorecard will show gaps for controls that were never configured, and your team can remediate those incrementally. A full re-onboard through the governed workflow is only needed if you want to re-provision credentials or formally re-assign ownership with an auditable approval record.

Our platform team wants to own the golden paths and our security team wants to own the guardrail policies. Can both teams work in their own scope without stepping on each other?

Yes. Template authorship and policy authorship are separate permissions. Your platform team publishes and versions scaffold templates. Your security or compliance team authors the per-tier guardrail policies that run when a developer picks a template. Neither team can override the other's scope, and both sets of changes are recorded in the audit trail with the identity of who made them.

Beri developer kamu sebuah path, bukan tiket.

Minta demo, tentukan golden path, dan biarkan tim kamu meng-onboard service baru tanpa menunggu antrean. Self-host hingga instalasi air-gapped, atau biarkan kami yang menjalankannya untuk kamu.

Minta demoBaca dokumentasi