Every international outage shows the same pattern. Websites and internal services stay up, and the infrastructure seems to have passed the test. Hours or days later, the first deployment fails, a server that was restarted doesn't come back, or a device's clock drifts far enough that two-step sign-in stops working.

The problem isn't that services depend on the internet. It's that building, updating and restarting them does, and those dependencies stay invisible until the day you need them.

The dependencies nobody lists

  • Package repositories — apt, npm, pip and go download from servers abroad by default. Every build and every fresh install needs them.
  • Container images — Docker Hub refuses requests from Iranian addresses, even on a normal day. A pipeline that starts with FROM node:22 depends on a foreign server in practice.
  • Time — servers take their clock from ntp.ubuntu.com or time.windows.com. Without synchronisation each machine drifts by seconds a day; after a few weeks, two-step codes, certificate validity and the order of your logs all go wrong.
  • DNS — servers pointed straight at 8.8.8.8 or 1.1.1.1 may fail to resolve even internal names during an outage.
  • Licence activation — some commercial software calls its vendor at every start, or every few days.
  • Alerting — if monitoring alerts only go out through a foreign service, none arrive on the day you need them most.
  • Website assets — fonts, scripts or a CAPTCHA loaded from a foreign CDN make the page slow or broken for local users.

A local replacement for each

DependencyLocal replacement
OS packagesAn internal mirror with aptly or apt-mirror
npm, pip and Maven packagesA caching proxy such as Nexus or Verdaccio that fetches each package once and keeps it
Container imagesAn internal registry such as Harbor with tested base images
TimeAn internal NTP server (chrony) the other machines sync from
DNSAn internal resolver that forwards to several upstreams
AlertingA channel that works from inside the network, such as SMS or a domestic messenger
Website fonts and scriptsServed from the website's own server

One note on caching proxies: fetching on demand is not enough. A package nobody ever requested isn't in the cache on the day of the outage. For critical dependencies, fetch the whole dependency tree once, on an ordinary day.

Pin your versions

A mirror only helps if the build knows exactly what it wants. Keep lock files such as package-lock.json, poetry.lock or go.sum in the repository, and name base images by their full version rather than a tag like latest:

FROM registry.internal/base/node:22.12-bookworm

Rehearse the outage

The best way to find hidden dependencies is to cut the link on purpose. In staging, block outbound traffic to the outside world for a day and do the following:

  1. A full build from scratch, without cache
  2. A deployment of a new version
  3. A restart of one server and one database
  4. A two-step sign-in, and a look at every machine's clock
  5. A test alert

Whatever fails is a dependency that wasn't on the list above. Write it down, and repeat the exercise every few months; new dependencies arrive silently.

In summary

Being ready for an outage means you can build, deploy and restart on the internal network, not just keep serving. Start with time and packages: every build needs the packages, and every two-step sign-in needs the right time.