Coming soon
Every file, agent-ready on arrival.
pks-agent-ftp
An FTP/SFTP server where every uploaded file lands with sidecar metadata — fully formed and ready for an agent to act on, the moment the transfer completes.
Files arrive. Then nothing happens.
A camera in the field, a scanner on the network, a device that only knows how to push files over FTP — they all speak a protocol from another era, and then they stop. The file sits in a folder. Someone has to notice it, copy it, name it, and feed it into whatever comes next. Between the upload and the work, there is always a human, a script glued together at midnight, or a SaaS middleman holding your data. The handoff is where it breaks.
Devices speak FTP, not your stack. Cameras and field hardware push files and assume someone is on the other end — there rarely is.
A raw file is not a trigger. There is no clean, reliable signal that says "this upload is finished and here is everything you know about it."
The glue layer is someone else's. The usual fix is a third-party ingestion service you don't control, parked between your device and your data.
How it works
Run the server
One small Go binary, a username, a password, a folder. That is the whole install.
Point your device at it
On a Sony A7: Network → FTP Transfer, enter the host, user, and password. Hit shoot.
Every file lands with its metadata
As each upload completes, the file is saved and a `.meta.md` sidecar is written beside it — who sent it, when, from where, its size and SHA-256.
Your agent watches one folder
The sidecar appears only after the file is fully written, so its arrival is the one reliable "ready" signal. Watch for it, and act.
Built for cameras
Tested against the Sony α7 series' built-in FTP transfer, including the passive-mode quirks real cameras depend on.
A sidecar for every file
Each upload gets a Markdown + YAML `.meta.md` recording user, timestamp, source IP, original path, size, and SHA-256.
A trigger you can trust
The sidecar is written only after the upload closes, so an agent watching for `*.meta.md` never acts on a half-written file.
Structure preserved
Uploads keep the device's own folder layout under `uploads/<user>/`, so `DCIM/100MSDCF/` arrives exactly as the camera laid it out.
One container, one volume
Ships as a single Docker image with a persistent volume — drop it on a Hetzner host or into Coolify and it keeps your uploads across restarts.
Honest about its limits
v0 is plain FTP for a trusted network or VPN — no hidden surprises, with FTPS as the documented, deliberate next step.
We wrote the server, not assembled it. A small Go FTP server built from the foundation up, not a fork of someone else's ingestion platform. Every behavior — the passive-port range, the sidecar contract, the write-then-signal ordering — is a decision we made on purpose.
Your data never leaves your disk. Files land in a folder you own, on a host you run. There is no third-party ingestion service between your camera and your storage — nothing to breach, nothing to trust but yourself.
It runs everywhere a container runs. One image, a named volume, a port range. Direct Docker on Hetzner or managed through Coolify — same binary, your infrastructure, no platform lock-in.
The sidecar is a contract, not an accident. A plain Markdown + YAML file any tool can read, designed so the next layer of the suite can build on it without ever needing to understand FTP. The foundation holds; everything above it composes.
Composes with
Your camera uploads. Your agent gets to work.
A small FTP server you own end to end. Point a Sony A7 — or any device that speaks FTP — at it, and every file lands on disk with a machine-readable sidecar. The instant the upload finishes, an agent has everything it needs to begin.