Iran's international internet link went down twice in the past year for long stretches: about 20 days from 8 January 2026, then 88 days from 28 February to 26 May 2026. The country's communications minister put the cost at roughly 5,000 billion tomans per day. Even in September 2026, local reports still described the connection as unstable, with scattered outages.
You don't have to operate in Iran for this to matter. National shutdowns, long cable cuts and sanctions that switch off a cloud account overnight all produce the same situation: the domestic network is up, the rest of the internet is not, and you find out which of your systems were quietly depending on the rest.
Some of the systems we run for clients sit on Iran's network, including one server that has had no outbound internet at all since May 2026. This post is what that setup taught us about what has to stay local, where the hidden dependencies were, and what to check before the next outage.
"Hosted locally" is not the same as "works locally"
A server in a domestic data centre is only the start. The useful question is: if only the national network is left tomorrow, what does this system still need from outside the border to do its daily job? The list tends to be longer than people expect. Fonts from Google Fonts, JavaScript from a foreign CDN, sign-in with Google, an SMS provider's API, certificate renewal, Docker image pulls, and lately a call to a hosted AI model. Any one of them can take down a system that looks local on the network diagram.
Email takes the first hit
Email is felt first because it is both the internal communication tool and the recovery path for everything else: password resets, verification codes, notifications. An organisation whose mailboxes live on Gmail or Microsoft 365 loses access to its own internal mail in a full shutdown, since a message between two people in the same office still travels through a server on the other side of the border.
A self-hosted mail server behaves differently. Mail between two mailboxes on that server never leaves the local network. Mail to outside domains isn't lost either; the SMTP server queues it and keeps retrying. What you need to know is how long the queue holds. Many servers bounce a message after a few days, and that window is useless in an 88-day outage. If outbound mail matters to you, know your queue lifetime and tell users what a bounce means.
We moved a university with about 10,000 mailboxes from a commercial service to a self-hosted server, and the cost dropped by roughly 90%. That project was about cost, not resilience, but a side effect is that the university's mail has no dependency on any foreign service. If you are weighing the options, why most local email hosts don't support custom domains covers a related trap.
"Sign in with Google" is the first thing to break
If staff log into internal systems with a Google or Microsoft account, an outage locks them out of every connected system, not just email. The same goes for verification codes sent through a foreign SMS gateway.
In our own systems we use a local identity provider (the university's own single sign-on, or the national government SSO) and one-time codes sent through a domestic SMS panel. Authenticator apps like Google Authenticator keep working offline, since they compute the code from the device clock. We wrote up the SMS decision in SMS login, not just an authenticator app.
Running a server with no internet at all
Since May 2026 we have run a server that deliberately has no outbound access. A research document archive with AI search (EnergyFile), the Probe361 standards lookup and a dashboard all run on it. Working that way changes a few habits that everyone ends up needing during a shutdown:
- Nothing gets downloaded at runtime.
docker pullandnpm installdon't work there. We build the full image elsewhere, stream it over SSH withdocker save, anddocker loadit on the other end. If your update process needs a public registry, you can't ship even a one-line bug fix during an outage. - Deploys don't take the service down. Every image transfer is slow, so the deploy script starts the new container next to the old one, waits for its health check, and only then swaps. If the new one never turns healthy, the old one keeps serving.
- The frontend loads nothing from a foreign CDN. Fonts and libraries ship inside the image. A page that pulls its font from Google Fonts sits blank for several seconds during an outage, and users assume the system is down.
TLS certificates: the clock nobody watches
This one we learned the hard way. Let's Encrypt certificates last 90 days and normally renew on their own. The usual method, HTTP-01, needs Let's Encrypt to reach your server on port 80 from outside. From late June 2026 that inbound path started failing for several of our domains, and automatic renewal stopped without any visible error. The existing certificates were still valid, everything looked fine, and nobody noticed until the expiry dates got close.
We now renew with DNS-01 from a machine that has internet access, then copy the certificate files onto the offline server. For some domains a domestic CDN manages the edge certificate. The lesson is simple: write down every certificate's expiry date and set a reminder. In a shutdown, automatic renewal is the thing you should not count on.
AI and external APIs fail silently
A system we maintain for a university client did automatic translation through a hosted model, reached through a tunnel. After a configuration change the tunnel stopped working, and translation was dead for about a month before anyone noticed, because the code swallowed the error and just showed the untranslated text. There was no national outage involved. Picture the same pattern across a three-month shutdown.
For another university's AI assistant we went the other way from day one. The whole system was built and tested against a local mock provider, and the hosted model is one replaceable layer. The vector database and documents are meant to live on the university's own server, not in a cloud service. The design goal is that if the model is unreachable, document retrieval keeps working and only answer generation stops, with a message the user can understand. Any feature that depends on an outside service should make its failure visible.
The tools people do their actual work in
After email and login come the operational tools: the helpdesk, shop-floor software, inspection apps. They fail in two ways. Either the server is abroad and the tool is simply gone, or the server is local but the user works somewhere with no reliable network at all, like a fabrication shop floor or a construction site.
For the first case the answer is an installation on your own server or a local data centre. When you buy a helpdesk or repair-shop system, ask whether it can run on your own hardware and how updates reach it without internet. For the second case the app has to be truly offline: data stored on the device, synced when the link comes back. Our Fidar MES for steel fabricators and Probe361's offline favourites are built that way. We explained the difference between real offline and cosmetic offline in true offline vs fake offline.
A checklist for before the next outage
This fits in a two-hour session with your IT team:
- List every system and write down where its server is.
- For each one, spend a day using it from a network with domestic-only access. Whatever breaks is a hidden dependency.
- Email: are mailboxes on a local server? How many days does the outbound queue hold?
- Login: does anyone need a Google or Microsoft account to sign in? Where are verification codes sent from?
- Certificates: record each domain's expiry date, and have a renewal method that doesn't need inbound port 80 from abroad.
- Updates: can you deploy a new version without Docker Hub or npm?
- Backups: where are they stored? If it's a foreign cloud bucket, you can't reach it during an outage.
- AI and external APIs: what does the system show when they are unreachable?
FAQ
Can a self-hosted mail server still send to Gmail? Yes, whenever the international link is up, like any other mail server. During an outage outbound messages wait in the queue and internal mail keeps working.
Is hosting in a local data centre enough? It's necessary, not sufficient. Small dependencies like fonts, CDNs, Google sign-in and certificate renewal have to go too.
What's the difference between a local system and an offline app? A local system survives the international link going down. An offline app keeps working when the user has no network at all. Shop floors and field inspections need the second.
Nobody can predict the next outage. The right time to find hidden dependencies is while the connection still works and you can test the alternatives calmly.
