Should devcontainers report offline readiness before launch?

A devcontainer should tell me whether it is actually ready to run without the network before it launches. “Local” is misleading if the image still needs a registry pull, a Feature download, VS Code Server or extensions from the internet, npm credentials, license checks, or a cloud service. Those dependencies should be visible, not discovered after a train ride starts or a customer site loses connectivity.

For example, a Node API container can look fully configured while its private package install waits for an npm token and its database sidecar image is uncached. A readiness report could distinguish cached items, required authentication, and services that will fail offline. Running with no network is a useful final test, but not much of a diagnosis.

I’m not arguing every team should cache the universe: caches add storage, update, vulnerability-management, and credential-handling costs. Should IDEs, package managers, or devcontainer tools provide a standard dependency-and-network manifest? Share counterexamples or existing tools that already solve this.

The useful distinction is “launchable offline” versus “reproducible offline.” A cached image may start while a lifecycle command quietly curls a script or the app expects a sidecar. I’d want the report to show network attempts during build and startup, not just parse configuration files.

The specification point matters here: supporting images, Features, services, and extensions does not itself create a universal offline manifest. I’d support a report, but it should label inferred dependencies separately from declared ones. Otherwise people will mistake an incomplete inventory for a guarantee.

Please keep credentials out of the report. “Authentication required” is useful; printing token locations, registry usernames, or secret-derived URLs is not. Also, offline readiness is not a security property. A fully cached, vulnerable image can be more dangerous than a failed pull.

For solo work I’d settle for a blunt preflight: missing image, missing package, missing extension, missing license, missing service. I don’t need a standards committee before I can code. A machine-readable format can come later if several tools converge.

The wording will shape behavior. “Offline ready” sounds like a promise; “network dependencies detected” is more honest. Give me a launch button with a clear warning and a way to inspect the dependency, rather than blocking every project by default.

Counterexample: some projects are intentionally online. A cloud extension or remote test service may be the product, not an accidental dependency. The report should expose the choice, not imply that offline capability is the universal quality bar.

The maintenance burden is real in larger teams. Stale caches create their own incident path, especially when nobody knows who refreshes them or which license obligations changed. I’d want an owner and last-verified time beside each cached dependency.

A manifest cannot catch everything. Build scripts can construct URLs dynamically, package managers can invoke hooks, and an extension can phone home after startup. The no-network container test is still valuable because it measures behavior instead of trusting declarations.

I’d separate network destinations from credentials. Knowing that a build contacts a registry is governance data; knowing how to authenticate is secret material. A signed manifest could help, but only if tools make provenance and changes visible.

This sounds like a good preflight feature because it answers a costly user question before the spinner starts. The product challenge is avoiding a wall of warnings. Show the blockers first, then optional connectivity and freshness details.

We used to call this documentation, except documentation was allowed to lie by omission. I’m in favor of a boring manifest generated from the actual build, with a boring failure when it is stale. No need to market it as a new philosophy.

Enterprise teams would also care about license checks and private registry policy, but those vary by organization. A standard could define fields without defining every approval rule. Local policy can decide whether an uncached or unauthenticated dependency blocks launch.

I’d ship the smallest useful version: a dry run that reports required pulls, auth prompts, and unavailable services, plus an optional network-denied test. If it saves one failed setup during an outage, that is already a decent return.