v1.3.1

Changelog

Other

• cd718b2: Call it 1.3.1 in the places that name a version (@fatihbaltaci)
• a153a2b: Let the image tag be the only place the OCI package names a version (@fatihbaltaci)
• 355ae64: Stop telling caches to keep a file that expires (@fatihbaltaci)

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.3.1

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.3.0

Changelog

Other

• bcd1e09: Call it 1.3.0 in the places that name a version (@fatihbaltaci)
• d019413: Name this server in the MCP registry (@fatihbaltaci)
• f4ad898: Speak the Model Context Protocol (@fatihbaltaci)

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.3.0

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.2.6

Changing a setting is the same command with the setting on it

godrop init --base-url https://files.example.com on a machine that was
already set up printed an update nobody asked for and dropped the flag on the
floor. A setting named on the command line is an instruction to change it:

$ godrop init --base-url https://files.example.com
  ✓ GoDrop is already set up in /home/you/.godrop

Changing
  ✓ base url               https://files.example.com

Updating
  ✓ the container is running the newest image

The value is checked before anything is written, the .env keeps its token,
its comments and every line you did not mention, and the service restarts into
the change. --port reaches the compose file that publishes it, and the volume
that file names is read back out of it first, so an installation keeping its
uploads on the host is not moved onto a fresh empty one.

--base-url, --port, --max-file-size, --max-total-size, --retention,
--tls, --tls-cert, --tls-key and --telemetry all work this way.
--force still means "set it up again from scratch".

Also

The closing summary asks for a token with godrop token create, which reaches
the file wherever it is, rather than with a docker command; and the diagnosis
reports the round trip once rather than from both sides of the container.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.2.6

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.2.5

The commands do the work, wherever the files are

A compose installation keeps its token file, its uploads and its telemetry
marker in a volume this machine cannot open. The answer to that used to be a
docker command to copy, which is not an answer: you asked GoDrop to make a
token.

token create, token list and token revoke now run where the file is, in
the running container or a throwaway one when the service is stopped, using the
same binary the service runs. The output is the one a local installation
prints, --json included.

$ godrop token create --name claude-code

Token created

  ┌─────────────────────────────────────┐
  │ gd_e92b1706682a8625484b3e4b7ac54567 │
  └─────────────────────────────────────┘

  ✓ name: claude-code (usable immediately, no restart needed)

godrop telemetry off reaches the one that would send

It wrote its marker beside this shell and reported that nothing more would be
sent, while the container carried on sending: the marker it reads is in the
volume. It is written there now, and telemetry status asks the container,
which is the copy that knows.

godrop doctor asks the container about the container

The storage, the permissions and the token file are inside it; the network and
the reachability are out here. Both are checked and one report comes out,
rather than a command to run for the other half.

godrop uninstall takes the service with it

It left the container running and the uploads on a volume it never mentioned.
It now stops the service and removes the container and its network, and with
--purge the volume as well, before deleting the configuration that says where
they are.

Also

godrop health probes the port the installation listens on rather than the
default one.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.2.5

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.2.4

The installer updates the godrop you already have

An install could leave two binaries: the new one in ~/.local/bin and an older
one in /usr/local/bin, earlier in the PATH. The wizard that ran was the new
one and the godrop that answered afterwards was the old one, which is a
confusing way to be out of date.

The new binary now lands on top of the installation in use when that directory
can be written to. When it cannot, it says which copy is shadowing it and how
to remove it:

⚠ another godrop is earlier in your PATH: /usr/local/bin/godrop
  that is the one that answers when you type godrop

      sudo rm /usr/local/bin/godrop   # then the new one takes over

--version

godrop --version answers, because that is what people type. godrop version
still says more.

A fresh install starts the newest image

Setup ran docker compose up -d with whatever :latest already meant on the
machine, so a host that had run GoDrop before started an old release and the
setup that had just verified it said everything was fine. It pulls first now,
as the update path does.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.2.4

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.2.3

Installing needs no root

The installer used sudo to reach /usr/local/bin. It does not any more: 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. Root is used when you are already root, or when you name the
destination yourself with GODROP_BIN_DIR, and never behind your back.

The one privilege this does need, once, is membership of the docker group.
The checks now ask the daemon rather than only the plugin, before anything is
written:

✓ docker compose         available
⚠ docker                 the docker daemon does not answer this user
    → start it, or join the group once: sudo usermod -aG docker $USER  (then log out and back in)

godrop update says what it needs

Updating a binary in /usr/local/bin as an ordinary user failed with
"permission denied" on a temporary file nobody had heard of, after downloading
the whole archive. The directory is checked first now, and the message is the
command that gets past it:

error: /usr/local/bin is not writable by this user, so the binary cannot be replaced.

  Try:  sudo godrop update

sudo changes where the installation is, too: root's own configuration directory
is empty, and the compose service that needs updating belongs to whoever ran
setup. Every command that looks for an installation now follows SUDO_USER
home when root has none of its own.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.2.3

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.2.2

godrop on its own no longer tries to start a server

Typing the name of a program is a question. On a machine already running
GoDrop, the second server failed for want of a token in the shell's
environment, which read as though the first one were broken. The bare command
prints the help; the image asks for the server with CMD ["serve"], so
docker run ghcr.io/fatihbaltaci/godrop is unchanged.

Token commands look where the tokens are

godrop token list on the host reported none to somebody holding the token
setup had just printed. It reads the installation now, and says which file that
token comes from and why it has no name:

$ godrop token list

  - 1 token(s) come from GODROP_TOKENS in /home/you/.godrop/.env, including the one setup gave you
  - they have no name here; edit that file to change them, and restart the service

  - named tokens live in the container:
      docker compose --project-directory /home/you/.godrop run --rm godrop token list

godrop token create used to write into ./data on a compose host, a file the
service never reads. It now prints the command that reaches the real one, and
on a systemd or .env installation it writes into the data directory that
installation actually uses.

The README says what this is for

Coding agents can take a screenshot and cannot attach it: GitHub has no
supported API for putting an image on a pull request. Upload it here, paste the
URL. The same recipe is in the agent skill and in /llms.txt, so an agent finds
it without being told.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.2.2

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.2.1

godrop doctor finds your installation

Run from a shell, doctor read only the environment, which is not the service's:
it reported no tokens, the wrong data directory and a 401 on the round trip. It
now reads the .env setup wrote. A compose deployment keeps its files in a
volume nothing outside the container can see, so that one is checked over HTTP
and the command for the rest is printed with the report.

The installer lands on your PATH

~/.local/bin is added to the PATH at login, and only if it already exists, so
a binary installed there was invisible to the shell that installed it. The
installer now prefers /usr/local/bin, and when it cannot, it adds the line to
your shell profile and prints the one to run now.

Setup ends with where everything is

Your installation
  - location             /home/you/.godrop
  - service              docker compose, container godrop-godrop-1
  - uploads              docker volume godrop_godrop-data
  - address              http://localhost:8747

Use it
      curl -X POST -H "Authorization: Bearer gd_..." -F "file=@/home/you/.godrop/sample.png" ...

  A token of its own for an agent, a script or a second machine:
      docker compose --project-directory /home/you/.godrop run --rm godrop token create --name claude-code

Also: /data in the image is 0700, which a fresh named volume inherits, and
godrop token create prints the address this instance actually answers on.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.2.1

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.2.0

Installing again is an update

Running the installer, or godrop init, on a machine that already has GoDrop
on it now updates that installation instead of asking the questions a second
time. The .env, the token and the uploads stay exactly where they are:

curl -fsSL https://godrop.sh/install.sh | sh

✓ GoDrop is already set up in /home/you/.godrop
- to configure it from scratch instead: godrop init --force

Updating
  ✓ the container is running the newest image

A compose deployment is pulled and recreated, which replaces the container and
keeps the named volume; a systemd one is restarted into the new binary.
godrop update does the same to the service, because the binary it replaces is
the command line and the service may be a container running a different copy.

Two questions fewer

Setup no longer asks whether to start the service, or whether to send the
anonymous heartbeat. It starts it, and the heartbeat is a notice at the end
with the command that turns it off.

"Use the recommended limits?" is now a choice between two named routes rather
than a yes and a no that hid what each one meant:

Limits
? Settings
  > Recommended: 100MB per file, 20GB quota, no expiry
    Advanced: set the sizes, the expiry and the port yourself

A busy port is caught before anything is written

The port question says so while the answer is being typed, and the checks that
run before the first file is written offer the next free port:

✗ port                   8747 is already in use
? Use port 8748 instead?

Without a terminal it stops with the flag that fixes it, and nothing has been
created.

The first example uploads a real file

Setup writes sample.png, the GoDrop logo, next to the configuration, and the
example it prints points at that file by full path. Pasting it uploads
something.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.2.0

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.

v1.1.0

The upload response changed

One shape for every upload, whether it carried one file or ten:

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

The same URL now also comes back in the Location header, where HTTP puts the
address of a thing a POST just created.

Breaking: the top-level url is gone, and so are id and mime, which
the URL already contains. size is now size_bytes, because a number without
a unit is a guess. A client that read .url should read .files[0].url.

Uploads can expire

curl -X POST -H "Authorization: Bearer $GODROP_TOKEN" \
  -H "X-Expires-In: 7d" -F "file=@invoice.pdf" https://files.example.com/upload

30m, 12h, 7d, 30d. ?expires= does the same for clients that cannot
set a header. The response then carries expires_at, the file stops answering
when it runs out, and the instance's retention period is the cap.

Setup asks less and finishes the job

• godrop init now checks the things that used to fail at the very end
  (the data directory, docker, systemd, the port) before it asks anything, so
  a setup that cannot work says so on the first screen rather than the last.
• It runs docker compose up -d and the health check itself instead of
  printing them for you to paste.
• Compose deployments no longer ask where to keep the files: they get a named
  volume.
• Everything it writes goes to ~/.godrop (%APPDATA%\GoDrop on Windows),
  not the directory you happened to be standing in.
• On macOS every question took two presses of enter. One now.

godrop uninstall

Removes what godrop init created, lists it first, and asks. It only deletes
generated files it can prove it wrote, and it refuses outright when the binary
came from apt, dnf, brew or scoop, pointing at those instead. --purge adds
the uploaded files.

Install

curl -fsSL https://godrop.sh/install.sh | sh

Or with Docker:

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:v1.1.0

Debian and RPM packages are attached below; they set up the systemd service
for you. Every archive's checksum is listed in SHA256SUMS.