Scale Your Platform Without Becoming the Bottleneck: The JFrog Projects Framework

Every growing engineering organization hits the same wall eventually. More teams shipping software means more repositories, more permission requests, more onboarding cycles, and eventually one platform admin fielding every change. The platform that was supposed to accelerate delivery becomes the constraint. JFrog’s Projects framework is a structural solution to that specific failure mode.

The Framework

The root cause of platform bottlenecks is rarely technical — it’s an ownership model that routes all access changes through centralized gatekeepers. JFrog Projects shifts the model: each Project is a bounded workspace with its own admin, repositories, roles, and security policies. The Platform Admin creates Projects and sets global policies but doesn’t own day-to-day access management. The Project Admin handles their team’s workspace with full authority over their scope and no access outside it.

The principle is “isolation by default, controlled collaboration by exception.” Rather than managing blast radius after a security incident, the architecture prevents cross-project exposure from the start.

One Project Per Team

The recommended starting model maps one Project to one stable, accountable team — the unit by which your organization tracks cost and ownership. JFrog customers have scaled this model to 120,000+ source-code repositories and support 35,000+ users with fewer than five platform staff, using project-to-application mapping.

The three-tier role structure prevents reversion to centralized management: Platform Admin creates projects and sets global policy without daily micromanagement; Project Admin has full authority within a single project workspace; Project Roles adjust automatically based on artifact lifecycle stage (DEV vs PROD environments auto-restrict permissions).

Delegated Administration

Short-lived, project-scoped tokens replace static credentials. Integration with GitHub OIDC or Microsoft Entra ID means a compromised credential affects only the team whose identity was exposed. JFrog Advanced Security vulnerability scanning runs isolated per project — a finding in one team’s workspace doesn’t require global triage.

The delegation model eliminates the common failure: “we need a new repo” routed to platform admin → ticket created → reviewed → approved → provisioned. Financial services implementations using template-based project provisioning report “zero-touch onboarding” — teams self-provision within a governed template structure.

AI Asset Governance

The framework extends to AI supply chain assets — model artifacts, MCP servers, agent skills — through JFrog’s AI Catalog and MCP Registry, both of which can be scoped per project. As AI tooling proliferates across engineering organizations, the same “one team, one scope” model that works for code artifacts applies to AI infrastructure. Per-team AI asset policies replace the current default, which in most organizations is platform-wide access with no meaningful isolation.

Where It Doesn’t Apply

The Projects model assumes a team structure stable enough to serve as an organizational anchor. Organizations in rapid restructuring — frequent team merges, splits, or ownership changes — will pay a maintenance tax as Projects are reassigned. The model also requires meaningful buy-in from team leads who become Project Admins: the delegation only works if those admins actually own their workspace rather than routing decisions back to the platform team by habit.

Source: JFrog Blog

Content created with AI assistance and reviewed for accuracy.