Building in Restricted Environments: How We Solved SoHoLINK's Module Download Challenge

Published February 6, 2026

At NTARI, we're building SoHoLINK—a distributed edge computing platform that transforms any SOHO network into a node of community infrastructure. As we develop technology designed to operate in this diverse network environment, we sometimes face those same constraints in our own development workflows.

The Challenge

One of our SoHoLINK developers encountered a common but frustrating problem: their development environment blocked outbound HTTPS connections needed to download Go module dependencies. When they ran go test ./..., instead of downloading packages from proxy.golang.org and github.com, the requests were redirected to 127.0.0.1:9—a dead end that returned connection refused errors.

They tried the usual workarounds:

• Configuring cache directories to avoid permission issues

• Setting GOPROXY=direct to bypass the proxy

• Disabling telemetry and checksum databases

Nothing worked. The network security policy simply wouldn't allow the external connections Go needed.

This put them in an impossible position: unable to download dependencies, unable to run tests, unable to build the project.

The Solution: Dependency Vendoring

Rather than wait for network policy changes or set up internal proxy infrastructure, we used Go's built-in vendoring feature. Here's what we did:

1. Created a vendor directory on a system with network access by running go mod vendor

2. Committed 262MB of dependencies directly into the repository (3,977 files)

3. Pushed to GitHub, where Git's compression reduced it to 45.29 MiB

4. Configured the developer to use GOFLAGS=-mod=vendor

Now when the developer runs go test ./..., Go uses the bundled dependencies instead of attempting external downloads. Problem solved.

Why This Matters for Community Infrastructure

This isn't just a technical workaround—it reflects a core principle of NTARI's approach to community-owned technology:

Infrastructure must work in real-world conditions. We're building SoHoLINK for home owners, libraries, and small offices that may have limited, filtered, or unreliable internet connectivity. If we can't build our software under network constraints, how can we expect it to operate reliably in those environments?

Self-contained systems are resilient systems. By vendoring dependencies, the SoHoLINK codebase becomes more portable and less dependent on external services. A developer in rural Kentucky with spotty internet can work just as effectively as one in a San Francisco tech hub. A Teen Tech Center can build and deploy updates even when their upstream connectivity is degraded.

Transparent problem-solving builds trust. Rather than hiding technical challenges, we document and share our solutions. When we encounter obstacles in building community infrastructure, our approach is the same: identify the constraint, adapt the solution, share the knowledge.

Practical Takeaways

If you're working on Go projects in restricted network environments:

For developers:

# Set this environment variable
export GOFLAGS="-mod=vendor"

# Now build and test without network access
go test ./...
go build ./...

For maintainers:

# Create vendor directory (requires network access)
go mod vendor

# Commit to repository
git add vendor/ go.mod go.sum
git commit -m "Add vendored dependencies"
git push

Trade-offs to consider:

• Pro: No network dependencies, faster builds, consistent versions

• Con: Larger repository size, manual updates needed

• Best for: Corporate environments, air-gapped systems, distributed teams

Looking Ahead

As SoHoLINK moves toward pilot deployment, we're building development practices that mirror our deployment philosophy: resilient, distributed, and community-centered. Every technical decision—from dependency management to infrastructure design—asks the same question: Will this work for the communities we serve?

The answer to network-restricted development is the same as our answer to centralized cloud infrastructure: bring the capabilities local, make them self-contained, and build for the constraints of the real world.