Sovereign Hub-and-Spoke: Deploying OpenTAKServer for Multi-Site Border Security

TAK — the Team Awareness Kit ecosystem — has quietly become the default common-operational-picture layer for a growing list of non-US public-safety and border-security agencies, not just the US military units it was built for. The pattern shows up constantly in systems-integration work: an agency running several remote sites (border posts, ports, checkpoints) wants a shared live map, fed by drones, perimeter sensors, and vessel-tracking feeds, without handing operational data to a foreign-controlled cloud. TAK — specifically the open-source server implementations, not the export-controlled official one — is usually the right answer. Getting the architecture right the first time is not.

This post walks through a sovereign, multi-site OpenTAKServer deployment we scoped for a border-security operator running several independent sites, generalized here because the architectural decision at its center — federation versus a shared hub — comes up in almost every multi-site TAK deployment we’ve evaluated, regardless of country or agency.

1. The problem: one picture, several independent sites

The operational requirement is easy to state and hard to satisfy cleanly: several field sites, each needing to keep functioning — showing its own local map, logging its own events — even when its link back to any central hub goes down, then re-syncing automatically the moment connectivity returns. Layered on top of that: drone/UAV telemetry, perimeter/fence IoT, and AIS vessel-tracking feeds all need to land on the same shared map as normalized CoT (Cursor on Target) messages, visible to field teams in ATAK, WinTAK, or iTAK.

Sensor feeds don’t arrive as CoT natively — a bridge has to normalize and sign each source’s data into CoT messages before anything downstream can use them.

flowchart TD
    A[Drone or UAV telemetry] --> D[CoT bridge]
    B[Perimeter or fence IoT] --> D
    C[AIS vessel tracking] --> D
    D --> E[TAK hub]
    E --> F[Site 1 edge node]
    E --> G[Site 2 edge node]
    E --> H[Site 3 edge node]
    E --> I[Site 4 edge node]
    F --> J[ATAK / WinTAK / iTAK clients]
    G --> J
    H --> J
    I --> J

That diagram looks simple. The hard part is the box in the middle-right: what happens to each site when its link to the hub drops. That single question is the biggest architectural fork in a deployment like this.

2. Why the official TAK Server usually isn’t on the table

Before getting to server architecture, most sovereign or non-US deployments run into the same wall: the official TAK Server (GOTS — Government Off-The-Shelf) from the US TAK Product Center is export-controlled under ITAR. Access requires US Person status or a government-to-government sponsorship path such as a Foreign Military Sales case — not something reachable through an ordinary commercial systems-integration engagement. That rules it out on eligibility grounds, not technical merit, for most non-US agencies evaluating TAK. Two open-source alternatives fill the gap: OpenTAKServer (OTS) and FreeTAKServer (FTS), both fully open-source with no export gate.

3. The decision that determines everything else: federation

A hub-and-spoke design — one central hub federating out to several independent edge servers, each holding its own local data and re-syncing deltas when the link returns — is the architecture every multi-site agency asks for first. It’s also the architecture that depends on true multi-server federation, a feature OpenTAKServer has not yet shipped. As of this writing it sits in OTS’s own "Planned Feature" list, with no implementation in the codebase — not partial, not in beta, simply not built yet.

Until it ships, the only available fallback is connecting every site directly to one shared TAK server over VPN or satcom, with no server running locally at each site. The mechanical difference between the two options matters more than it looks:

• With federation: each site keeps its own CoT/mission store. The link to the hub only ever carries the delta. Losing the link costs sync, not operation.
• Without federation: the link is the only path to any TAK capability at that site. Losing it takes the site fully offline until the link returns.

For a border-security or maritime-security customer operating in satcom- or cellular-dependent terrain, a comms dropout during an active incident is a realistic condition, not an edge case — which makes this a genuine operational decision, not just an architectural footnote. It’s also, deliberately, not a decision an integrator should make silently on the customer’s behalf: it needs an explicit answer before pricing and Phase 0 are finalized, because it changes both the technical build and the fee.

FreeTAKServer, by contrast, has federation shipped today — traded against its own weaknesses: SQLite-by-default storage versus OTS’s PostgreSQL orientation, and upstream development that has slowed noticeably (single active primary maintainer for OTS versus a project for FTS whose last confirmed update, at review time, was over a year old). Neither is a clean win; both trade-offs are real and worth testing in a readiness phase before committing.

	OpenTAKServer (OTS)	FreeTAKServer (FTS)
License	GPL-3.0	Eclipse Public License
Language	Python	Python (Flask)
Federation	Planned, not yet shipped	Shipped — current feature
SBC / Raspberry Pi support	First-class design target	Should run, less battle-tested
Database	PostgreSQL-oriented	SQLite / SQLAlchemy by default
Video streaming	Yes (MediaMTX)	Limited
Maturity	Active, single primary maintainer	Federation shipped, upstream slower

The practical resolution we use: evaluate both directly against the customer’s connectivity and hardening requirements during a readiness phase, rather than betting the architecture on either project’s roadmap sight unseen. If independent site operation during an outage turns out to be a hard requirement and FTS’s trade-offs are unacceptable, a custom federation-equivalent bridge for OTS becomes its own scoped line item — not something quietly folded into a fixed fee.

4. What’s actually available on OpenTAKServer today

Setting the federation gap aside, OTS’s shipped feature set covers most of what a field deployment needs out of the box: ATAK/WinTAK/iTAK/WebTAK/CloudTAK/PyTAK connectivity, SSL/TLS, client-certificate enrollment, a WebUI with a live map, mission groups/channels, LDAP/Active Directory integration, an ATAK plugin update server, messages/points/routes/images/live-location sharing, CoT database storage and data packages, alerts and CasEvac, video streaming, and a Mission API. That’s a wide enough surface that federation is genuinely the only gap that changes the architecture — everything else is configuration, not a missing capability.

5. A phased rollout that doesn’t gamble the federation decision away

The federation question doesn’t need to block kickoff — it needs to be closed out early, with a defined phase whose job is specifically to answer it before the expensive phases start.

flowchart TD
    P0[Phase 0: Readiness assessment] --> P1[Phase 1: Hub setup]
    P1 --> P2[Phase 2: Edge node configuration]
    P2 --> P3[Phase 3: CoT bridge development]
    P3 --> P4[Phase 4: Hardening UAT and validation]
    P4 --> P5[Phase 5: Training and handover]

Phase 0 does the double duty of a site/connectivity review, a hardware spec the customer can take to procurement, and the federation decision — tested against real site conditions rather than assumed on paper. Everything downstream — hub hardening, per-site edge configuration, the sensor bridges, failover testing — is sized differently depending on that one answer, which is exactly why it belongs at the front of the timeline and not somewhere in the middle of it.

A realistic total for a four-site deployment of this shape runs 5–6 months from kickoff to handover, with a 30-day hypercare window after training. Pricing scales with the same federation decision: a baseline scenario (cellular connectivity everywhere, no federation-equivalent bridge needed) sits well below a higher-complexity scenario (a custom federation bridge, multiple satcom sites, extended compliance documentation) — often a 20–25% spread between the two ends, which is exactly why the decision gets closed out in Phase 0 rather than assumed at the proposal stage.

6. What we’d add if you want to go further

Once the core hub-and-spoke deployment is live, the same CoT event stream opens up further integration work that’s worth scoping separately rather than bundling into a fixed base fee: custom ATAK/WinTAK plugins for site-specific SOPs, additional sensor bridges (CCTV/NVR analytics, ANPR, radar, SCADA), a two-way bridge into a SOC stack so cyber detections appear as geolocated CoT events and TAK incidents open as SOC cases, on-prem LLM analysis that reads the CoT stream to draft situation reports without any data leaving the sovereign environment, machine-vision object detection on drone and CCTV feeds, sensor-fusion alert correlation to cut false positives across drone/fence/AIS signals, and anomaly detection on AIS/GPS patterns to flag dark-vessel behavior or loitering automatically.

None of this is included in a base hub-and-spoke build. Listing it up front matters more than it sounds — it’s the difference between a customer discovering scope creep mid-engagement and a customer choosing, deliberately, which of these to add and when.

7. Who this is for

This architecture pattern fits any multi-site operator — border security, port authorities, critical-infrastructure operators, large-perimeter facilities — that needs a shared, sovereign common operational picture across sites with unreliable connectivity, and that can’t or won’t route operational data through the export-controlled official TAK Server. The federation trade-off discussed above applies whether you’re running two sites or twenty; it just gets more expensive to get wrong at scale.

8. Working through this with your own sites

If you’re evaluating TAK for a multi-site deployment, the federation question above is worth answering before any vendor conversation, because it changes what you should be pricing and who you should be asking. Simplico scopes and delivers OpenTAKServer/FreeTAKServer deployments — hub setup, edge-node configuration, sensor-to-CoT bridging, PKI, hardening, and training — as a services-only engagement: no hardware supplied or marked up, professional services only.

Reach out at hello@simplico.net to talk through your site count, connectivity constraints, and sensor mix.