Modern software supply chains are complicated enough, CI, local developer machines, multiple environments. The system protecting them should not add more complexity than necessary.
ShieldedStack's long-running application architecture is built around three clear units: the Portal, the Proxy, and the Worker. Each has one distinct purpose and is deployed separately, so capacity can be added where it is needed.
That gives customers a deployment that is easy to understand on day one and straightforward to grow over time.
Three units of scale
The Proxy: where package decisions happen
The Proxy is the entry point for package-manager traffic. Developers and CI systems continue to use their normal package-management tools, with ShieldedStack configured as the package source, this can happen either on the network level or on a per project configuration level.
When a package is requested, the Proxy applies the organization's policy and either allows the request to continue or blocks it before the package enters the development environment. This is the latency-sensitive part of ShieldedStack, so its responsibility remains narrow and predictable.
Most customers run one Proxy. Customers that need additional availability, greater request capacity, or separate ingress points can run multiple Proxy instances and place them behind their normal traffic-management layer.
The Worker: where background work gets done
Workers handle the work that should not delay a package request or an operator using the Portal. This includes processing package activity, keeping package intelligence current, evaluating new information, and preparing notifications and other follow-up actions.
Every Worker is equivalent. There are no special Worker roles for customers to assign and no need to decide which instance handles which type of task. Add another Worker and it joins the available processing capacity.
Customers commonly run multiple Workers. This improves background throughput and gives the deployment resilience when an instance is restarted or temporarily unavailable.
The Portal: where people manage ShieldedStack
The Portal is the management surface of ShieldedStack. It is where security and platform teams sign in, review package activity, manage policies, investigate risk, and administer their ShieldedStack environment. It also provides the APIs customers use to integrate that management capability with their own tools.
It is the control point for the deployment, but it is not in the path of every package download. Keeping the management experience separate from package traffic means administrative activity does not compete with the day-to-day work of developers and build systems.
Most customers run one Portal for their ShieldedStack deployment.
The Typical Customer Deployment
A common production deployment looks like this:
- 1 Portal for administration, visibility, and policy management
- 1 Proxy for package traffic
- 2 or more Workers for background processing and resilience
The exact number of Workers depends on the amount of package activity and background processing in the environment. Scaling does not require dividing them into different roles: customers add replicas of the same Worker unit. A single Proxy is enough for most customers, while multiple instances can be introduced without changing how developers use ShieldedStack.
How a Package Request Moves Through ShieldedStack
From a customer's perspective, the flow is intentionally short:
- A developer or build system requests a package using its existing package manager.
- The request reaches the ShieldedStack Proxy.
- ShieldedStack evaluates the package against the organization's policy.
- An allowed package continues from its upstream package source; a denied package is stopped.
- ShieldedStack records the activity for the Worker pool to process in the background and for teams to review through the Portal.
The immediate decision stays on the direct request path. Collection, enrichment, reporting, and follow-up work happen outside that path. This separation keeps package access responsive while still giving security teams the context and visibility they need.
Scale the Work, Not the Architecture
Each ShieldedStack unit has a natural scaling signal:
| Unit | What it serves | Typical deployment | Scale when |
|---|---|---|---|
| Portal | Security, platform, and administrative users | One instance | Typically remains a single application unit |
| Proxy | Developers, CI systems, and package-manager requests | One instance | You need more request capacity, availability, or additional ingress points |
| Worker | Background processing | Multiple instances | Background volume grows or you want more processing resilience |
This is the core of ShieldedStack's scaling model: add capacity to the unit doing the work. More package traffic does not require creating new kinds of services, and more background activity does not require specialist Worker roles.
Designed to Fit the Customer's Environment
ShieldedStack's architecture is intentionally uneventful. It runs inside the customer's environment and fits into the operational standards already in place around it. Customers can deploy the application units on their preferred container platform and integrate them with their OIDC identity, traffic management, monitoring, backup, and secrets-management practices.
These three units are the long-running ShieldedStack applications, not the entire platform footprint. They operate on customer-managed data services and identity, with deployment-time tasks handling setup and upgrades. Those supporting services follow the customer's own availability and governance requirements.
The same application units apply whether ShieldedStack begins as a small evaluation deployment or runs as part of a larger production platform. The topology stays recognizable as usage grows.
That consistency matters operationally. Platform teams can see what receives traffic, what performs background work, and what needs to scale without learning a large map of internal services.