Citizen developer infrastructure

Current state

The full ABCD framework described below is the target end state. Today only some pieces are in place; the rest is being designed and evaluated.

What we have now

Source code repository

Citizen-developer projects must live in a single, centralized place so AI Ops can apply branch protection, CI/CD pipelines, and security scanning uniformly across all of them.

If you have GitLab access, push your project to the dedicated group: gitlab.com/docebo/internal-citizen-developers.

The intake skill scaffolds a new repo there with the standard templates (agents.md, .gitignore, branch-protection rules) so you don’t start from scratch.

If you don’t have GitLab access, we’re actively working on a path for non-engineering colleagues — likely a managed flow where AI Ops creates the repo on your behalf and gives you a controlled write surface (GitLab Web IDE, MR-based pushes from Claude Code, or similar). In the meantime, reach out to AI Ops on Slack or via #ai-ops and we’ll set the project up manually.

Deployment platforms

These are the enterprise deployment platforms either in active use or under evaluation for citizen-developer projects. None of them is yet wired to a self-service pipeline — every deployment today still goes through AI Ops.

Default network access: behind CATO

Apps built by citizen developers should be placed behind CATO by default, so they’re only reachable from the corporate network (employees on the Docebo SASE/SSE). Exceptions — public-facing apps, third-party integrations, partner access — must be discussed up-front with AI Ops and the Security team.

When configuring an IP allowlist (in nginx, Coolify, Vercel Trusted IPs, AWS security groups, etc.), use these CATO egress IPs:

185.114.123.133/32
45.62.188.108/32
209.206.13.74/32

Document any deviation from this default in the project’s repo (a short note in the README or ACCESS-CONTROL.md is enough), so it’s clear later who approved the exception and why.

How to enforce this on Vercel (Trusted IPs)

Vercel has a built-in Trusted IPs allowlist under Deployment Protection. No edge middleware needed.

1. Open your project on Vercel → Settings → Deployment Protection.
2. Scroll to the Trusted IPs card.
3. Flip the toggle to Enabled and pick the scope (Production Deployments is the typical default; pick All Deployments if you want preview URLs gated too).
4. Under IP / CIDR, add the three CATO IPs one per row (Vercel’s UI accepts plain IPs and treats them as /32, so you can paste either 185.114.123.133 or 185.114.123.133/32). Label each row CATO so it’s obvious later who put them there.
5. Click Save.

Result: only requests originating from those three IPs hit the deployment. Anyone else gets a Vercel auth challenge.

Notes:

• Trusted IPs is a Vercel Pro / Enterprise feature. If your project is on Hobby it won’t show up — check with AI Ops to move the project to the Docebo team plan.
• Maximum 20 IPs per project; we use 3.
• Leaving the scope on Production Deployments keeps preview URLs publicly reachable, which is usually what you want for stakeholder review. Switch to All Deployments if previews must be gated too.
• If a single endpoint must remain public (e.g. /api/webhook for a third-party integration), use Deployment Protection Exceptions in the same panel rather than turning the whole allowlist off.

How to enforce this on Coolify / nginx

See ACCESS-CONTROL.md for the full nginx config the AI Hub itself uses (X-Real-IP checks against the same three CATO IPs, plus a Glean crawler exception). Use it as the template for any internal app deployed on Coolify.

Where we want to go

The sections below describe the target App Building for Citizen Developer (ABCD) — the end-to-end flow from idea to autonomous, governed deployment. These pieces are in design and not yet operational.

The problem we’re solving

Rapid AI adoption has led to tech sprawl: apps built without review, unauthorized deployments, fragmented tooling. ABCD introduces a clear path from idea to production, with the right security checkpoints along the way.

Complete workflow

Every step is designed to be as frictionless as possible for business users while maintaining the governance required.

How projects get assessed

The conversational intake guides the citizen developer through a series of questions that determine the required review level and deployment path.

How the pieces connect

The infrastructure is designed to separate citizen developer work from operational control, keeping the pipeline secure and automated.

Roles and responsibilities

Every actor has a clear role in the process. The goal is to minimize the burden on citizen developers by shifting complexity to the operational teams.

Tools and platforms

The strategy is to consolidate on a few quality tools, avoiding the tech sprawl that created confusion in the past.