Developer Onboarding

A checklist worth copying into your own onboarding material. Five things stand between a new machine and a tracked install.

1. An API key. Generated in Settings -> API Keys, with a project name that identifies the application or repository the developer works on.
2. The proxy base URL. Every package-manager configuration is built from <proxy-url>.
3. The key in the environment. SHIELDEDSTACK_API_KEY in a shell profile or local secret store, so committed configuration files can reference it instead of carrying it.
4. The package manager configured. The ecosystem page for the language they work in.
5. Credential files ignored. Confirm the secret-bearing files for that ecosystem are in .gitignore before the first commit.

Verify before you call it done

Run a restore or install, then check Packages in the Control Plane. The package should appear with the project name from the API key. A successful install that produces no entry means the request did not go through the proxy, which is worth catching on day one rather than the first time a policy is supposed to block something.

What tends to go wrong on a new machine

A pre-existing config file. Developers arriving from another project often have a ~/.npmrc, pip.conf, or ~/.m2/settings.xml already pointing somewhere else. Existing user-level configuration usually wins over what they just added.

Scoped registry overrides. In npm, a single @scope:registry= line sends part of the dependency tree straight to the public registry while everything else looks correctly configured.

A key pasted into a committed file. Worth checking on the first commit rather than discovering it in a scan later. Each ecosystem page shows the environment-variable form that is safe to commit.