Deployment and Rollout

Deployment Sequence

This section is critical. The deployment steps must be performed in the exact order below. Performing them out of order will cause package installs to fail.

flowchart LR
    Step1["1. Configure JFrog Artifactory\n(repos, Package Reroute API,\nanonymous access, redirect)"]
    Step2["2. Install Zscaler CA\nand trust configuration\non workstations"]
    Step3["3. New terminal sessions\n/ IDE restart\n(pick up env vars)"]
    Step4["4. Activate ZIA rules\n(URL category, SSL inspection,\nredirect rule)"]

    Step1 --> Step2 --> Step3 --> Step4

Required Order of Operations

Warning: If ZIA rules are activated before Artifactory is configured or before certificate trust works for your package clients, installs can fail with SSL errors (missing or untrusted CA) or HTTP errors (Artifactory not ready). That can be disruptive at scale. Mandatory mass reboots alone do not fix this: remind people that new terminals or an IDE restart pick up updated environment variables. Always follow the sequence above.

Gradual Rollout Recommendation

To reduce risk, deploy PTC gradually rather than to the entire organization at once. You can phase by people (labs, pilots, departments—often using Zscaler Groups) and also by package ecosystem: turn on interception and routing for one registry or client stack at a time (for example npm first, then PyPI, then Docker/OCI later) by narrowing the ZIA URL category and matching Artifactory Package Reroute / repo_key configuration. You do not need to redirect every supported package type on day one.

Gradual rollout: space workstation readiness from ZIA activation

The Deployment Sequence already requires Artifactory first, then Zscaler CA and client trust on workstations, and only then ZIA rules that intercept registry traffic. In a gradual rollout, treat that last step as time-shifted from the earlier steps—not every machine receives certificates, trust-store updates, or install scripts on the same day, and open terminals and IDE-embedded shells keep the old environment until developers open a new tab or restart the IDE (see Step 3 in the deployment table).

Practical pattern:

• Pilot or department first: Push workstation trust and client configuration to a small cohort, give them a short soak window (communication + a few days is common), and verify installs against the redirect path before you enable or widen ZIA interception for that cohort.
• Then enable ZIA for the same cohort (scoped Groups in ZIA align with who is supposed to be on the new path). Avoid turning on SSL inspection and redirect rules for a population that has not yet had trust and env changes land—or you will see TLS failures and support noise that are not Artifactory defects.
• Expand in waves: Add the next batch of workstations (MDM, imaging, or manual steps), wait for readiness signals (spot checks, helpdesk volume), then extend ZIA scope or the next Zscaler Group—rather than enabling ZIA org-wide while certificates are still propagating.
• Same idea inside a phase: Even when you only change ZIA (for example adding a second registry domain to the URL category), confirm the clients that will hit that domain already have trust and env guidance applied for that stack before you flip the rule.

This is complementary to phasing by package ecosystem and by Zscaler Groups: you are also phasing when the network starts intercepting relative to how far along endpoint preparation is.

Why Gradual Rollout Is Important

Rolling out every user and every package client at the same time carries risk:

• The installation script may encounter edge cases on specific workstation configurations that cause breakage.
• Unforeseen interactions with existing security policies, network configurations, or developer tooling may surface.
• If something goes wrong, the blast radius is the entire developer population and every language/runtime that shares the same rules.
• Different package managers (npm vs. pip vs. container pulls) have different TLS and tooling quirks; phasing by package type isolates those variables.

A phased approach—by audience, by registry domains in ZIA, and by which ecosystems you have configured end-to-end in Artifactory—lets you identify and resolve issues with minimal disruption.

Recommended Rollout Phases

Phasing by package type (optional): Within any phase above, you can keep ZIA’s custom URL category minimal (e.g., only registry.npmjs.org until npm is stable), then add domains for PyPI, container registries, Hugging Face, and so on as you validate each stack. Align Artifactory Package Reroute repo_key settings so only ecosystems you intend to govern are in the path. This is independent of JFrog vs. Zscaler ownership: Zscaler controls which hostnames are intercepted; JFrog controls which repository serves each type.

What to Monitor at Each Phase

• Package installs succeed without SSL errors
• Download and install time stays acceptable for your teams (throughput may differ from a direct path to the public registry—for example on first fetch, cache miss, or extra redirect hops—so compare against your own baseline and adjust capacity or caching if installs feel too slow)
• Packages appear in Artifactory's cached artifacts
• Curation audit log shows expected entries (only if JFrog Curation is enabled on the resolving remotes)
• Artifactory system logs show package reroute lines (user, original and target URLs, registry type, user agent)—see Package reroute logs (Artifactory)
• npm audit and other POST-based commands continue to work normally
• Lock file behavior is acceptable (see Lock file considerations (npm) — minor URL differences are expected and not a blocking issue)
• No unexpected workstation or application breakage from the installation script
• When you add another registry domain or package client to the rollout, re-run targeted smoke tests for that client (install, lock files, TLS) before expanding scope further

Consumption Impact for SaaS Customers

If your JFrog Artifactory instance is a SaaS (cloud-hosted) subscription, be aware that deploying PTC will affect your consumption metrics.

How Consumption Is Affected

When PTC is active, all developer workstations that install packages through the redirected flow will generate traffic against your JFrog Artifactory instance. This means:

• Every package download that was previously going directly to the public registry will now be routed through and served by your Artifactory instance.
• Each workstation added to the PTC deployment increases the total volume of requests and data transfer against your Artifactory subscription.
• Cached packages reduce repeated upstream fetches, but the initial download of each package version will count toward consumption.

Recommendation

Before deploying PTC across your organization, review your current SaaS subscription limits and projected consumption increase with your JFrog account team. The gradual rollout approach (see Gradual Rollout Recommendation) also helps you monitor consumption growth incrementally rather than experiencing a sudden spike.

Frequently Asked Questions

This section provides answers to frequently asked questions about deploying Package Traffic Controller (PTC).

Related Topics

• Package Traffic Controller (PTC) overview
• Prerequisites and Installation Script
• Configure Artifactory for PTC