GoDrop

Upload a file, get a hard-to-guess URL.
A drop box your coding agents can use: one Go binary, no database, your disk.

That is the whole idea. Downloads need no token; uploads and deletes do.

curl -X POST \
  -H "Authorization: Bearer $GODROP_TOKEN" \
  -F "file=@photo.jpg" \
  https://files.example.com/upload

{
  "files": [
    {
      "url": "https://files.example.com/f/20260815-143022-8f4e2c91b7934b38a72d1c0e5b6a4f3d/photo.jpg",
      "name": "photo.jpg",
      "size_bytes": 12345
    }
  ]
}

Why this exists: screenshots in pull requests

Coding agents write the code, run the tests and open the pull request. Asking them for a screenshot is the cheapest way to review the branches you are never going to check out and run yourself. They can take one: they start the app, drive a browser and capture the page. Then they cannot attach it.

GitHub has no supported API for attaching an image to a pull request. The web interface takes a drag and drop, and that is the whole of it (cli/cli#4228, #1895, #12960 "critical for agentic workflows", community#28219). What is left is committing binaries into the repository, an undocumented upload endpoint that can stop working on any deploy, or a bucket with a policy, a key and a bill attached to it.

An agent that can run curl can do this instead:

URL=$(curl -sS -X POST -H "Authorization: Bearer $GODROP_TOKEN" \
  -F "file=@login-after-fix.png" $GODROP_URL/upload | jq -r '.files[0].url')

gh pr comment 42 --body "Login page after the fix:

![login]($URL)"

The identifier carries 128 random bits and the URL needs no token to open, so GitHub renders it inline for everyone on the thread. The file itself is on your own disk, which is where a picture of your unreleased work belongs, and it can delete itself: -H "X-Expires-In: 30d".

Nothing about this is specific to screenshots. It is the same three lines for a video of a flaky test, a profile, a build log too long for a comment, or a generated report. What an agent needs to do it by itself, including a skill it can install, is in For AI agents.

Install

curl -fsSL https://raw.githubusercontent.com/fatihbaltaci/GoDrop/v1.3.1/install.sh | sh

The script picks the right binary for your machine, verifies its SHA-256 checksum against the published SHA256SUMS, installs it, and hands over to a setup wizard that writes your configuration, creates your first token and checks that the internet can actually reach you.

No root anywhere. The binary goes to ~/.local/bin, the configuration to ~/.godrop, and the uploads into a docker volume, so updating and removing GoDrop later are the work of the same account. Run it as root, or set GODROP_BIN_DIR=/usr/local/bin, to install it for everybody instead. The one thing that does need root, once, is being in the docker group; setup checks that before it writes anything.

Other ways:

# Docker: comes back up after a reboot, and after a crash
docker run -d --name godrop --restart always \
  -p 8747:8747 \
  -e GODROP_TOKENS=$(openssl rand -hex 16) \
  -v godrop-data:/data \
  ghcr.io/fatihbaltaci/godrop

# Debian or Ubuntu: installs the systemd service and creates its user.
# Download the .deb for your architecture from the releases page:
# https://github.com/fatihbaltaci/GoDrop/releases/latest
sudo dpkg -i godrop_1.3.1_linux_amd64.deb

# Fedora, RHEL or openSUSE
sudo rpm -i godrop_1.3.1_linux_amd64.rpm

# From source (Go 1.26+). Binaries built this way send no telemetry at all.
go install github.com/fatihbaltaci/GoDrop/cmd/godrop@latest

Every package, archive and checksum is on the releases page, and the container image is at ghcr.io/fatihbaltaci/godrop.

Platforms

The suite runs on Linux, macOS and Windows for every change, and each release artefact carries signed build provenance:

gh attestation verify godrop_1.3.1_linux_amd64.tar.gz --repo fatihbaltaci/GoDrop

Guided setup

$ godrop init

  GoDrop 1.3.1 setup
  Upload a file, get a hard-to-guess URL.

  Public address
  ? Public URL              https://files.example.com
  Service
  ? How should it run?      docker compose
  HTTPS
  ? Certificate             GoDrop gets one from Let's Encrypt
  Limits
  ? Settings                Recommended: 100MB per file, 20GB quota, no expiry

Checks
  ✓ storage                docker volume godrop-data
  ✓ output directory       /home/you/.godrop
  ✓ docker compose         available
  ✓ port                   443 is free

Written
  ✓ /home/you/.godrop/.env  (chmod 600, contains your token)
  ✓ /home/you/.godrop/docker-compose.yml
  ✓ /home/you/.godrop/sample.png  (a picture, so the first example below uploads something)

Your API token

  ┌─────────────────────────────────────┐
  │ gd_7f3a9c2e1b8d4a6f0c5e2d9b3a7f1e4c │
  └─────────────────────────────────────┘

  ⚠ shown once and never again, so copy it now

Starting
  ✓ containers started

Verifying
  ✓ firewall               ufw allows port 443
  ✓ firewall               ufw allows port 80
  ✓ external access        reachable (HTTP 200, from FRA)

Use it
      curl -X POST -H "Authorization: Bearer gd_7f3a…" \
        -F "file=@/home/you/.godrop/sample.png" https://files.example.com/upload
      ...

Anonymous heartbeat
  - once a day: {install_id, version, os, arch, deploy}
  → turn it off any time with: godrop telemetry off

Four questions, and the last one is a choice between the recommended limits and setting them yourself. Everything the answers depend on is checked before a single file is written, so a setup that cannot work says so at the start rather than at the end, and the service is started and verified here rather than left as a command to paste. The picture is there so that the first command you paste uploads a real file.

Answering "GoDrop gets one from Let's Encrypt" is all HTTPS takes: it obtains the certificate itself and renews it, so there is no proxy to install and nothing to configure. The question only offers it for a name Let's Encrypt can actually issue for, and the listen port question disappears, because serving TLS means 443.

Changing your mind later is the same command with the setting on it. The token, the uploads and every answer you do not mention stay where they are, and the service restarts into the change:

godrop init --base-url https://files.example.com   # or --port, --retention, --tls…

Every question shows its default and can be answered with a flag instead, so CI and agents run the same code path without a terminal. Prompts are skipped automatically when there is no TTY; --no-input makes that explicit:

godrop init --no-input \
  --base-url https://files.example.com \
  --data-dir /var/lib/godrop \
  --max-total-size 20GB --json

The wizard only offers what the host can do: systemd appears on Linux, not on macOS or Windows, and the commands it prints use the right shell.

The API

Nine endpoints, no SDK, no client library: an agent that can call curl has everything, and GET /llms.txt describes this exact instance in plain text.

# Several files at once: all succeed or none do, and the response lists them
# in the order they were sent
curl -X POST -H "Authorization: Bearer $GODROP_TOKEN" \
  -F "file=@a.png" -F "file=@b.pdf" -F "file=@notes.txt" \
  https://files.example.com/upload