Daily deliveries to many customers, each of them huge
Satellite and aerial imagery providers, and the analytics companies that buy from them, move tiled datasets: GeoTIFF or cloud-optimised GeoTIFF tiles in their thousands, SAR scenes, and daily acquisitions that run to tens of terabytes. Each customer wants their footprint, on time, in a form their pipeline can ingest without a person clicking through a download page.
Ordinary uploads over TCP crawl over the distance to a customer on another continent, an FTP server leaves nobody sure which tiles arrived, and per-GB transfer services make a daily feed unaffordable.
Thousands of tiles as one verified job
Boita moves a folder of tiles as a single job over an accelerated transfer engine that uses UDP with its own rate control, holding your line rate whatever the distance, in parallel sessions sized to your plan. Transfers checkpoint and resume after any interruption; completed tiles are never re-sent.
The server records a checksum for every tile and shows it in the file details. Numbered sets such as scene_0001.tif to scene_0480.tif appear as one row with the range, count, size and a gap warning, so a missing tile is visible before the customer finds it. Delivery receipts carry per-tile checksums, verified downloads and a CSV verification report, with a PDF on Studio and above.
Fits the ground station, the pipeline and the customer’s bucket
A ground station or processing centre pushes acquisitions in through an upload portal or a watch folder on the headless Linux agent, which runs as a systemd service and is controlled from the web app. The boita command line and the REST API with TypeScript and Python SDKs create shares, start transfers and list files from a pipeline; signed webhooks tell it when a delivery lands or a customer downloads (Pro and above).
On Enterprise, auto-delivery pairs a workspace folder with the customer’s own S3-compatible bucket or transfer server: every tile that lands is pushed there within minutes, sub-folders kept, retried on failure, with a delivery log and a webhook per file. Import from an S3-compatible bucket works the other way, running on our servers rather than through a laptop. Azure Blob and native GCS connectors are coming; GCS works today through its S3-compatible endpoint.
A worked example
A 10 TB acquisition reaches the workspace from a processing centre on Enterprise, over a 10 Gbps line, in about five hours, plan-limited at 4.5 Gbps. A 1 TB customer subset goes out on Studio over a 2.5 Gbps line in about an hour, plan-limited at 2.25 Gbps. What the customer sees on the way down depends on the distance and loss on their side, which the calculator on the home page models.
- Line-rate, resumable transfers of tiled datasets; nothing re-sent
- Numbered tile sets as one row with gap detection
- Checksum per tile; receipts with a CSV verification report
- CLI, REST API, SDKs and webhooks for the pipeline (Pro and above)
- Auto-delivery to the customer’s S3-compatible bucket (Enterprise)
Controls for licensed data
Imagery is licensed, so every share link has an expiry, an optional password and a download limit, and can be revoked at any time; download tokens expire in minutes. Recipient verification by email code names the person who downloaded. Priority lanes send a deadline delivery ahead of routine ones, and bandwidth windows keep the daily feed off the office connection during working hours. An audit log is on every plan, exportable to your SIEM on Enterprise.