Running Clockspring in Air-Gapped or Restricted Networks

Many Clockspring deployments run in environments with limited or no outbound internet access. This includes air-gapped networks, highly restricted government environments, and segmented enterprise networks.

Clockspring is designed to operate in these conditions, but it helps to understand what connectivity is optional, what is required, and what changes operationally.

First: What “Air-Gapped” Usually Means in Practice

True air-gapped environments are rare. Most deployments fall into one of these categories:

• No outbound internet, but internal network access is allowed

• Outbound access is allowed only through proxies

• Only specific destinations and ports are permitted

• Inbound access is tightly controlled or blocked entirely

Clockspring supports all of these, but assumptions must be made explicit.

Outbound Connectivity Expectations

What Clockspring Does Not Require

Clockspring does not require:

• continuous outbound internet access

• cloud callbacks

• vendor-hosted control planes

• telemetry or usage reporting

There is no dependency on external SaaS services to keep the platform running.

What May Require Outbound Access (Optional)

Depending on how you use Clockspring, outbound access may be required for:

• calling external APIs

• pushing data to SaaS platforms

• downloading files from external endpoints

These are integration choices, not platform requirements.

In air-gapped environments, these calls are often:

• proxied

• routed through gateways

• replaced with file-based or message-based handoffs

Internal Communication Still Applies

Even in air-gapped environments:

• Clockspring nodes communicate with each other

• Clockspring communicates with the Registry

• Internal communication uses mTLS

Air-gapped does not mean unsecured. Internal TLS requirements remain unchanged.

Updates and Upgrades in Restricted Environments

Installation and Upgrades

In air-gapped environments:

• RPMs are staged internally

• package repositories are mirrored or manually managed

• upgrades are performed intentionally, not automatically

Clockspring does not self-update or pull binaries at runtime.

Dependency Management

Any OS-level dependencies must be:

• pre-approved

• staged

• installed as part of normal system management

This aligns with standard enterprise change control processes.

Inbound Integrations in Air-Gapped Environments

Inbound data from external systems is often the hardest problem.

Examples:

• external services pushing events

• partner callbacks

• webhook-style integrations

Direct inbound access to internal systems is usually not acceptable.

Recommended Pattern: Controlled Ingestion

The most common and security-friendly pattern is:

1. Use a DMZ-Based Ingestion Node

• A Clockspring node placed in a DMZ or boundary network

• Dedicated to receiving inbound data

• Minimal scope and permissions

• Preferably protected with mTLS

This node is intentionally exposed, but tightly constrained.

2. Terminate Inbound Traffic Securely

Inbound connections should:

• authenticate the sender

• be encrypted

• be narrowly scoped

Common controls include:

• mTLS

• IP allowlists

• limited endpoints

Avoid anonymous inbound access.

3. Hand Off Data Inward, Don’t Push It

The DMZ node should hand data inward using controlled mechanisms such as:

• writing to a database

• dropping files to object storage (for example, S3-compatible storage)

• writing to a message queue

Internal Clockspring nodes then pull data from these systems.

This avoids opening inbound paths into the protected network.

Why This Pattern Works Well

This approach:

• minimizes attack surface

• aligns with common security architectures

• simplifies firewall rules

• separates ingestion from processing

• scales cleanly as integrations grow

It is also much easier to get approved by security teams.

Common Mistakes in Air-Gapped Deployments

• Assuming outbound internet is required

• Allowing direct inbound access to internal nodes

• Mixing ingestion and processing roles on the same node

• Treating air-gapped as “no TLS needed”

Restricted environments still require strong internal security.

What to Decide Early

Before deploying in a restricted network, decide:

• which integrations require outbound access

• how inbound data will cross security boundaries

• where certificates are issued and trusted

• how upgrades will be staged and approved

These are architectural decisions, not processor settings.

Summary

Clockspring runs cleanly in air-gapped and restricted environments because it:

• does not depend on external control planes

• uses internal mTLS by design

• supports pull-based and staged data movement

• fits standard enterprise security models

With the right network boundaries and ingestion patterns, Clockspring operates reliably without direct internet access.