Bootstrapping an Air-Gapped Deployment in 30 Days

SIs promise air-gapped go-lives the way caterers promise monsoon weddings. The date is firm. The tent is not. Thirty days is enough to bootstrap a real disconnected path if you refuse to spend week one on a model bake-off and week four on a logo. It is not enough to invent a hall, a power feed and a records series.

This playbook assumes a home already exists — an SDC cage, a PSU DMZ island, a campus HPC VLAN — and that you have permission to isolate it. If you do not have a home, your first thirty days are a survey. Do not relabel a survey as a deployment.

The product of the month is not a demo. It is a run room that stays up with the network cut, a build room that can fill a bag, and a written no-go if any of that is fake.

What 'done' means on day 30

Artefact	Done	Not done
Network	Default deny out; allow-list empty or tiny	Proxy exceptions 'for now'
Identity	Officer SSO or local IAM, no shared root	vendor / vendor on the box
Registry	Pinned images inside, documented pull path	docker pull still in the runbook
Bag ceremony	One successful import with two people	SI laptop mounted as storage
Data	Sample corpus with ACL metadata	Whole drive copied 'temporarily'
Eval	[Gold set](/blog/air-gapped-model-evaluation-without-internet) scored offline, floor written	'Looks good' in a meeting
Observe	Logs to your SIEM or local equivalent	Vendor SaaS dashboard
People	Named owner + cover	WhatsApp group

The four weeks

Week 1 — Isolate and name

Cut the route first, even if the cluster is empty. An empty cluster with outbound is how helpers sneak in. Stand up a jump path that is identity-bound and recorded. Name the application owner, the admit officer, the SOC contact and the vendor lead. If a name is missing, stop expanding scope and start making phone calls.

• Write the high-side / low-side diagram on one page.
• Disable BMC outbound. Change default passwords. Inventory NICs.
• Choose media policy for the bag. Order a dedicated, numbered device.
• Request SIEM indexes and a test officer identity.

Week 2 — Registry, pins, first bag

Stand the private registry and the admit host. Build a minimum image set on the connected side: OS, runtime, your agent, a small model. Hash, scan, bag, admit, run. This is the week you discover that someone's 'offline installer' still curls GitHub.

Do not introduce the full model catalogue. One small model proves the path. Large weights can follow the same bag once the path exists.

Week 3 — Data plane and gold set

Stand object store, index and the ingest of a sanctioned sample — tens or hundreds of documents, not the archive. Sit with officers for gold items. Wire traces to the SIEM. Run the harness. You now have a system you can fail.

Week 4 — Prove the gap, prove the ops

Break the network in front of witnesses. Run the gold set. Import a dummy patch. Restore a snapshot. Tabletop the SI resignation. Write the go/no-go. If you need a temporary outbound to finish the show, the answer is no-go, not 'conditional go'.

1. Day 22–23: network-off demo on the real officer identity.
2. Day 24–25: dummy CVE bag. Time it.
3. Day 26–27: snapshot restore of the index.
4. Day 28: rota and leave-cover initials.
5. Day 29–30: note to the owner — go, no-go, or sandbox-only.

What to refuse during the month

• A second workflow. One purpose.
• Live personal data before the capture and the gold floor exist.
• Vendor remote tools that need persistent outbound.
• Fine-tuning. You do not have the factory yet.
• A press note. Day 30 is an internal go/no-go.

Objections you will hear — and what to do with them

We already have a Kubernetes cluster; skip to models.

If that cluster can talk to the internet, it is not your run room. Clone the idea, not the route.

Thirty days is too slow for the minister.

A dishonest day 10 is slower than an honest day 30, because you will spend the next quarter pulling helpers out. Offer a connected synthetic demo on a laptop for the minister and keep the enclave clean.

The vendor's appliance is zero-day.

Then unpack it into this calendar anyway. You still need identity, SIEM, gold set and a bag for the next patch. Zero-day appliances still have day 31.

The one-page calendar you can print

1. Week 1: cut routes, name people, BMC, bag policy.
2. Week 2: registry, first pinned bundle, first admit.
3. Week 3: sample ingest, gold set, SIEM, harness.
4. Week 4: network-off proof, dummy patch, restore, go/no-go note.

How this shows up in the file

File the day-30 note with the packet capture, the bag log, the gold report and the rota. If the answer is no-go, that is a professional outcome. The next thirty days then have a list. What you must not file is a screenshot and a promise to isolate later.

A RACI for the month so the calendar has owners

Artefact	Responsible	Accountable	Consulted
VLAN / deny-all	SDC network	CISO	SI
Registry + first bag	SI	Application owner	Admit officer
Identity / SSO	IAM team	Application owner	SOC
Sample corpus	Records officer	Process owner	SI
Gold set + floors	Process owner	DPO (if personal)	SI
SIEM mapping	SOC	CISO	SI
Go / no-go note	Application owner	CIO / HOD	All of the above

If a cell is both responsible and missing, that line is your critical path. Hire, second, or shrink the scope. Do not 'cover it in week four'. Week four is for proof, not for finding a records officer.

Daily stand-ups in this month should be artefact-based: show the capture, the bag log, the gold item count. Status colours without artefacts are how day 30 arrives with a chatbot and no deny-all.

What to tell a minister who wants a launch

Offer a laptop demo on public circulars, labelled as a demo. Offer a date for the enclave go/no-go. Do not offer a launch. Launches create citizens. Citizens create traces. Traces on a dirty network create the file you were trying to avoid.

This article is a field guide, not legal, procurement, electrical or engineering advice. Confirm numbers, duties and designs against the current Gazette, CERT-In directions, your SDC / NIC / campus standards, a site survey and your counsel before you file them.

How to prove this on a rack, not on a slide

“Bootstrapping an Air-Gapped Deployment in 30 Days” only matters if a CISO can fail it. A P4 Systems Integrator should be able to point at a cable, a registry, a licence file, a PDU reading or a SIEM index and say: this is the control. If the only evidence is a brochure that mentions “air gapped deployment timeline”, you do not have the control.

Thirty days will not give you a perfect enclave. It will give you a run room, a bag, a gold set and a go/no-go you can defend. Here is the calendar. Air-gap and on-prem programmes die in the second month, when the first update, the first crash, or the first GPU lead-time slip arrives. Budget the boring path — media, offline licence, local registry, local traces — in the same note as the model name.

On-prem is not air-gapped. An India region is not either. Write the forbidden path (outbound HTTPS, licence phone-home, crash reporter, hidden model API) as a numbered list and test it with the internet off. Whatever still dies was a dependency you did not draw.

1. Draw the data path for one user-visible answer under “air gapped deployment timeline”.
2. Disable outbound internet on staging and run the demo script.
3. List every remaining hop: update, licence, registry, NTP, DNS, SIEM.
4. Give each hop an owner inside the department, not only the SI.
5. Minute the restore or the media-transfer once before go-live.

Close this loop before the next CAB

Put “Bootstrapping an Air-Gapped Deployment in 30 Days” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P4 Systems Integrator, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “air gapped deployment timeline” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.