send-instances is a directory of public Send servers, kept in a single Markdown file

The entire repository is one README file

The send-instances project is described as a list of public Send instances, and it is a mirror. The repository top level listing contains exactly one file, README.md, and the homepage is on GitLab at gitlab.com/timvisee/send-instances, so the GitHub copy is the mirror rather than the source.

That single file is the product, and the reason it works as a directory is that the table is not written by hand. The project is a page, and the page is a live view.

The most important line in the README is the disclaimer, and it is short. This page does not give any promises or warranties with regard to instance security and reliability.

That sentence is doing real work, because the list is a list of services operated by strangers. The directory tells you where the instances are and what their limits are, and it explicitly declines to vouch for what happens to a file once you upload it. The table gives you the facts that are checkable, the limits and the uptime, and leaves the trust question to you.

The table of contents shows the structure of the page. Instances, How to use, Host your own instance, and Submit changes. So it is not only a list, it is also the instructions for using the list, the instructions for running an instance, and the contribution process for adding one.

The topics attached to the repository are firefox-send, hacktoberfest, list and send, and the hacktoberfest tag is a clue about how the list grows, since contributions of new instances are the kind of small change that open source contribution events generate.

What the columns actually tell you

The table header is the specification of the directory.

| Instance URL | Size limit | Time limit | DL limit | Links/Notes | Country | Version | Uptime | |---|---|---|---|---|---|---|---|

Eight columns, and the middle three are the ones that determine whether a given instance is usable for your file. The size limit ranges widely in the visible rows, from 50MiB for send.jeugdhulp.be and 512MiB for send.aslaets.be, through 1GiB for drop.chapril.org, 2.5GiB for several instances, 5GiB for send.monks.tools, 8GiB for send.mni.li and send.adminforge.de, up to 10GiB for send.cyberjake.xyz and send.turingpoint.de.

The time limit is how long a file lives before it is deleted, and the visible values are 3 days for send.vis.ee, 5 days for drop.chapril.org, 7 days for most of them, 10 days for send.jeugdhulp.be and 30 days for send.cyberjake.xyz.

The DL limit is the download count, and it is the column that changes the character of the service. Most instances sit between 10 and 100, send.aslaets.be allows 3, and send.adminforge.de allows 1,000. A download limit is a shareability limit, and a value of 3 means the file is effectively private, while 1,000 means the link is meant to be passed around.

The country column and the flag come from the instance's own country, and the visible rows are spread across the Netherlands, the United States, Turkey, Germany and France. That spread matters for a file sharing service, since the jurisdiction determines the legal framework the operator is working under, and the README gives no guidance on which instance to pick for which reason.

The Links/Notes column is where the maintainer information goes, a link to the person running the instance, a contact address, sometimes both and sometimes nothing, and the first row links both a maintainer and a contact page.

The version and uptime columns are fetched, not typed

The two rightmost columns are the interesting ones, because they are the only values in the table that are not a fixed fact about the instance.

The Version column is a dynamic badge. Each row uses a shields.io endpoint pointed at the instance's own version endpoint, the query is version and the url is the instance address with __version__ appended, so https://send.vis.ee/__version__ for the first row.

So every instance is asked, every time the page renders, what version it is running, and the answer is drawn as a badge. The same applies to the uptime column, where the badge points at a JSON uptime history in the tdulcet/send-instances-status repository, with a per-instance API path and a link to a history page for each one.

That design has a clear consequence. The size limit, the expiry, the download limit and the country are claims made by the operator when the entry was added, and they can be wrong or out of date. The version and the uptime are queried from the instance itself at render time, so they are current if the instance is reachable and they say nothing if it is not.

The uptime badge links to a history page, which means the project keeps a time series rather than a single current value, and a user can see not just whether an instance is up now but whether it has been flapping. For a service you are about to send a file through, that history is more informative than the row itself.

The country flags are rendered with a DuckDuckGo icon service, one request per instance address, which is a small detail that confirms the table is meant to be read in a browser rather than parsed as data.

What the README does not do for you

Two things stand out as absent from the visible content, and both are consequential.

The first is any advice on which instance to choose for a given file. The table has the facts, and the How to use section exists in the table of contents, but the visible text does not rank the instances or recommend one. A user with a 3 GB file has to read the size column themselves.

The second is anything about the protocol or the software behind Send. The list is a list of instances, and the project is not the software. The instances run Send, the Firefox file sharing service, and this repository does not describe how it works, how the file is encrypted or what happens to it. The list is infrastructure discovery, and the security properties of the service are inherited from the software, which is not in scope here.

That division is reasonable for a directory, and it is also the boundary a user has to think about. The list tells you that send.adminforge.de allows 1,000 downloads and is in Germany with a live uptime badge. Whether you should put a confidential file there is a question about Send and about that operator, and the README's disclaimer is what stands between the table and a false sense of endorsement.

The absence of tags on the version column for the first row is also worth noting. Some instances show a version badge and a maintainer link, others show a contact, and some show neither, so the completeness of the metadata varies by entry, which is what you would expect from a list maintained by contributions.

Where send-instances is the wrong tool

The first wrong case is a user with a confidential file. The README disclaims any warranty about instance security and reliability, and the operators are volunteers. A file uploaded to a public Send instance with a 1,000 download limit and a 7 day expiry is on a machine the user does not control, and the directory does not change that. For a medical record, a contract or a credential, the right answer is a self-hosted instance, and the Host your own instance section is the relevant part of the page for that.

The second wrong case is a user who wants an API. This is a Markdown page with a table, not a service with an endpoint. A program that needs to choose an instance has to scrape the README and parse the badges, and the badges are rendered images, so the values behind them are the only machine-readable form. The version values come from a per-instance HTTP endpoint and the uptime from the separate status repository, so a machine would have to talk to each instance rather than to the directory.

The third wrong case is a user who expects the list to be complete. It is a contribution list, so it contains the instances whose operators submitted an entry, and a new instance that nobody has added is invisible. The size of the visible table is a dozen or so rows, and the Firefox Send ecosystem is larger.

The fourth wrong case is a team that wants the guarantees a curated directory gives. There is no editorial policy described, no review criteria and no removal process beyond the submit and contribute workflow, so the list is a record of who signed up rather than a set of instances that passed a check.

How it differs from the built-in Firefox Send list

The comparison worth making is with the instance list inside Firefox Send itself, and the difference in approach is where the information comes from and how fresh it is.

Firefox Send has a small built-in list of well known instances that the browser offers when you open the service. That list is curated centrally by the browser project, it is deliberately short so that a user has an obvious default, and the information it carries about each instance is minimal because the browser only needs an address.

This directory is the opposite in shape. It carries eight columns per instance, the size limit, the expiry, the download limit, the maintainer contact, the country, the version and the uptime, and it is a page you read rather than a dropdown you pick from. The size limit in particular is the information the built-in list does not surface, and it is the information that determines whether the instance is usable for the file you have.

The second difference is the freshness model. The built-in list is a static list in the browser, updated when the browser updates. This page queries each instance at render time for its version and pulls uptime from a continuously updated status repository, so the two columns most likely to be wrong in a static list are the two that are checked live here. The columns that cannot be checked live, the limits and the country, are the ones a user has to trust.

The third difference is the scope of the audience. The built-in list serves a casual user who clicks a link and uploads. This list serves people who care about the difference between a 50 MiB instance and a 10 GiB one, and people who want the uptime history before deciding.

The fourth difference is the relationship to the software. The built-in list is part of the browser project and changes with it. This list is an independent project, so an instance can appear here before or after it appears in the browser, and the two lists will not always agree.

Editorial conclusion

send-instances fits a Firefox Send user who wants to pick an instance with a known size limit, a known expiry and a visible uptime instead of whatever the built-in list offers, and it fits an operator who runs a Send instance and wants to be listed and to see their own uptime. It does not fit a user who needs a guarantee about what happens to their file, since the README says plainly that it gives no promises or warranties about instance security and reliability. Before picking an instance from the table, read the disclaimer and check the uptime and version badges yourself, and note that the canonical repository is on GitLab with the GitHub copy described as a mirror, and that the last push was on 2026-07-17.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. timvisee/send-instances on GitHub