DOCS

Documentation

Karshipta is two things: an open-source console and gateway you can self-host for free, and this hosted app at karshipta.com. This page covers karshipta.com; self-hosting docs live in the open-source repository.

Terminology

Karshipta uses a few words on purpose, consistently, everywhere - the app, the docs, the source code. Here's what each one means.

Karshipta: The platform itself: an open-source console and gateway you can run on your own infrastructure for free, plus this hosted version at karshipta.com.
Console: The live map and control dashboard you actually use - this is "the app," and it always runs in your browser, whether that's karshipta.com or a self-hosted copy.
Gateway: The piece that actually talks to your hardware: it speaks MAVLink (or Herald) to your wards and reports back to the console. Runs on a machine near your vehicles - either self-hosted, or via Karshipta Desktop for the hosted app. See the download page for that.
Fleet: The set of wards one gateway manages.
Ward: Karshipta's word for anything tracked and controlled: a multirotor, plane, VTOL, helicopter, ground rover, underwater vehicle, or boat - or a non-flight tracker like a livestock GPS tag. Deliberately broader than "drone," since not everything Karshipta tracks flies.
MAVLink: The open protocol most flight controllers speak (PX4, ArduPilot). If a ward has an autopilot, it talks to the gateway over MAVLink.
Herald: Karshipta's own open standard for anything that isn't MAVLink-capable: GPS trackers, livestock tags, sensors with no autopilot at all. Same map, same fleet, no flight controller required.
Mission: A saved flight path: an ordered list of waypoints one ward flies. Flight-only - it doesn't apply to a non-flight ward like a tracker.
Zone: A named boundary drawn on the map - keep-in (stay inside) or keep-out (no-fly). Advisory today: it warns before a mission crosses it, it doesn't block the autopilot from doing so.
Command: A single instruction sent to a ward - arm, take off, land, return home, go to a point. Always answered with an accept or a reason for rejection, never silently ignored.
Event: Something the gateway reports as worth a human's attention: link lost, low battery, a rejected command.

Self-hosting Karshipta

The gateway (C++) and the console (the web dashboard) are both AGPL-3.0 and run entirely on your own infrastructure. No account, no cloud dependency. The gateway speaks MAVLink to PX4/ArduPilot wards, and separately, Herald, our open tracking standard, to anything else that reports position and status without a flight controller: livestock tags, generic GPS trackers, cellular sensors. A deployment that only needs Herald can build karshipta-herald, a lean variant with zero MAVSDK linked.

Quickstart guide · clone, install, fly a simulated fleet in minutes
Architecture · how the gateway, console, and wire protocol fit together
Herald ingestion · native HTTP, mapped vendor payloads, and GT06 tracker support
Herald specification · the open message standard itself, maintained separately
Source on GitHub

The contract

proto/karshipta/v1

protoc → C++ (gateway) · ts-proto → TS (console)

Operator

Console

SvelteKit + MapLibre, one FleetStore keyed by ward_id

WebSocket LAN, direct

Relay relayly, NAT traversal

Edge process

C++20

Gateway

WardManager HeraldWardManager FleetManager

Two fixed release artifacts from one codebase: karshipta-gateway (MAVLink and Herald) and karshipta-herald (Herald only, zero MAVSDK linked). A build-time choice, never a runtime toggle.

karshipta-desktop is this exact process, wrapped as a signed Tauri sidecar for customers who would rather not touch a terminal. It runs on site with the ward, then reaches this app over the same relay shown above.

Flight MAVLink wards

MAVSDK

MAVLink
UDP 14540+

Action, Telemetry, Mission plugins, 2 to 10 Hz per ward

PX4 / ArduPilot. SITL container or a real autopilot. Simulation-first: everything works against SITL with zero hardware.

Only in the karshipta-gateway artifact.

Herald anything without an autopilot

Native

HTTP
POST /herald

Body is already a Herald message

Mapped

HTTP
/herald/mapped/<source>

Vendor's own JSON, translated by a declarative YAML field mapping

GT06

TCP
:5023

Hundreds of low-cost tracker models speak it natively

Tags & generic trackers. Livestock GPS tags, cheap GT06-family hardware, or your own integration. Three independent ways in, one shared ingest.

Present in both artifacts, zero MAVSDK linked.

Planned, not built

DJI bridge

A DJI-to-MAVLink adapter in front of this same gateway.

CoT bridgeissue 105

Translates Cursor-on-Target into a Herald message.

SensorThings bridgeissue 106

Same pattern, for OGC SensorThings sources.

Org scopingissue 104

Herald's org_id field has nowhere to land yet.

Considered, not building: Apple AirTag ingestion. Apple publishes no public location API, and the bridges that exist reverse-engineer Find My, which isn't a foundation for a real feature.

The guest map on karshipta.com

Landing on karshipta.com opens a live map with a silent, read-only session: no login, no tracking prompt. Clicking a ward shows its public telemetry (mode, altitude, speed, battery, link status); there is no path from a guest session to a command, by construction.

A seeded NIKX demo fleet keeps the map from ever being empty, alongside every signed-in account's own wards that are public by default. An operator's telemetry is sanitized before it ever reaches a browser: delayed, coordinate-decimated, home position never exposed. Paying for the Private Fleet add-on (see pricing) removes an account's wards from this feed entirely, account-wide.