Palmr is a self-hosted WeTransfer clone that its author has archived

The author archived it and said why

The first thing in the README is a notice that Project Archived, and it is unusually specific about the reason. After deep reflection, the author decided to focus limited time and energy on other projects. As a solo developer, he had struggled to actively maintain multiple projects with the care and attention they deserve, and without enough sponsors it became infeasible to maintain Palmr.

The notice invites forks and offers to add a link to one in the README. That is a more useful signal than a bare deprecation notice, because it tells you the code is not considered hostile to reuse and there is no relicensing question.

There is a mismatch worth naming rather than smoothing over. The README says archived, the repository metadata does not carry an archived flag, and the repository was pushed to on 2026-09-28. So the code is still moving in some sense while the project is declared finished. Treat the README notice as the authoritative statement of intent and the push timestamp as evidence that commits landed after it, not as evidence of a maintained release line.

The second notice is a beta warning rendered as a red banner: this project is currently in beta phase, not recommended for production environments. Every release tag carries the same suffix, from v3.3.0-beta through v3.3.2-beta, so the beta label is a naming convention the project never intended to graduate from.

Fastify, SQLite, Next.js, and where files actually land

The stack is described in a Technologies Used section. The backend is Fastify on Node.js with built-in schema validation, the database is SQLite for metadata and transactional data with zero configuration, and storage is the filesystem with optional S3-compatible object storage. The frontend is Next.js 15 with TypeScript and Shadcn/ui.

The zero-configuration claim is the part that matters most for self-hosting, and the compose file backs it up. Storage works with no setup at all by default, and switching to external S3 is a matter of uncommenting environment variables:

    image: kyantech/palmr:latest
    container_name: palmr
      # - S3_ENDPOINT=s3.amazonaws.com      # Your S3 endpoint
      # - S3_ACCESS_KEY=your-access-key     # Your access key
      # - S3_SECRET_KEY=your-secret-key     # Your secret key
      # - S3_BUCKET_NAME=palmr-files        # Your bucket name

Those lines are commented documentation inside the compose file rather than active configuration, which is a friendly way to ship a reference. The same block documents path-style URLs for MinIO, an option to reject self-signed certificates, and a region setting. Two container-level knobs exist for running as a specific UID and GID, which is the detail that decides whether the internal storage volume is writable when you are not root.

The Dockerfile explains where the S3 support comes from. The base is node:24-alpine with gcompat, supervisor, curl, wget, openssl and su-exec installed, and before any application code is copied in, two scripts under `infra/` install the MinIO server and the `mc` client. So the internal storage path is not SQLite blobs; it is a real object store running inside the container, with MinIO as the default and S3 as the alternative.

Reverse share, the feature borrowed from WeTransfer

The screenshot table is mostly navigation, but one entry stands out: Reverse Share, labelled WeTransfer Style in its caption. There is a default reverse share screen and a second one explicitly marked as the WeTransfer variant.

If you have used WeTransfer, you know the pattern. The recipient uploads files, and the sender gets a notification and a download link, without the two sides needing to be online at the same time. It is the feature that separates a file transfer service from a shared folder, and it is the hardest part to get right because the authorization model has to survive the sender being absent.

The release notes give a hint of where that logic has been fragile. v3.3.2-beta includes a fix for a 401 error on reverse share uploads for files of 100MB or more, which is a symptom of an upload path that diverges from the authenticated path at a size threshold. The same release fixes audio and video preview MIME type handling when behind a reverse proxy, which tells you that at least one deployment in the wild terminates TLS somewhere other than the app.

Other features listed as reasons to choose Palmr are folder organization for grouping and sharing, no artificial limits, and full control with no third-party dependencies. The comparison targets are named explicitly: WeTransfer, SendGB, Send Anywhere, and Files.fm. That list is a useful sanity check on scope, since all four are consumer-facing services where the differentiator is usually a file size cap.

Every release is a beta, and the newest one is a security bump

Three releases are visible, all within about a week in December 2025. v3.3.0-beta published on 2025-12-03, v3.3.1-beta on 2025-12-04, and v3.3.2-beta on 2025-12-10. The v3.3.0 notes describe the largest change in the set: the custom chunked upload was replaced with the Uppy library for multipart uploads, the download queue system was removed in favor of direct downloads with caching, drag-and-drop was added for moving files and folders, and optimistic UI updates were introduced.

That is a real refactor of the upload and download architecture, delivered as a beta, one day before a follow-up fix. The v3.3.1-beta release exists solely to implement multi-architecture support for the MinIO client installation, which is exactly the kind of follow-up you expect after changing how files move through storage.

The v3.3.2-beta list is the most valuable release data in the repository because it reads like a bug report from production use. It fixes a stale file manager after creating and renaming folders, a metadata resolution problem in share links, large file uploads failing above 10GB on S3-compatible storage, downloads failing in Firefox by adding a Content-Length header, a 401 on reverse share uploads for large files, and a 2FA button overflow on phones.

And it bumps Next.js to 15.3.6 to address CVE-2025-51605, described as a remote code execution vulnerability. That is the single most important line in the release notes for anyone running this: the last thing the author did was patch a critical advisory in a dependency. The last release predates 2026-10-06 by roughly ten months, so the pinned Next.js version is your responsibility now.

A small monorepo with a very large image

The repository root is short: a Dockerfile, a Makefile, a docker-compose.yaml, an `apps/` directory, an `infra/` directory, CONTRIBUTING.md, and two package files. The root package.json is named palmr-monorepo, marked private, pinned to pnpm 10.6.0, with a single devDependency on husky and one script that points git's core.hooksPath at .husky. The version field tracks the beta releases, currently 3.3.2-beta.

So the root package does almost nothing, and the real work is split across `apps/server` and `apps/web`. The Dockerfile confirms the split with separate dependency and builder stages for each, generating a Prisma client in the server stage before building, and the schema-driven client is why the database is described as zero-configuration.

The image itself is the surprise. Beyond the Node 24 base and the MinIO install, the Dockerfile describes distinct server-deps, server-builder, web-deps and web-builder stages, and a Makefile whose targets include build, start, stop, logs, clean and shell, with the build described as producing a multi-platform Docker image. A file sharing app with a frontend, a backend, a database, an embedded object store and a client SDK inside one container is a lot of moving parts to keep updated, which is the mechanical explanation for why the project stalled where it did.

The documentation lives off the repository at palmr.kyantech.com.br, and the Core Maintainers section names a single person. One open issue and 2,396 stars is a ratio that says most users never reported anything, which is a good sign for stability and a bad sign for knowing what is broken.

Editorial conclusion

Palmr is a well-built feature clone that hit the wall every solo-maintained project hits, and the README does not pretend otherwise. The code is worth reading for a specific reason: the reverse share, the folder model and the zero-config internal storage with optional S3 are all implemented at a level that suggests the author finished what they set out to build rather than abandoning it half-done. What you are adopting is a frozen v3.3.2-beta from 2025-12-10 that carries a Next.js bump for a remote code execution advisory, and the image tag in the compose file is `latest`, which on a project with no further releases means whatever Docker Hub last pushed. Fork it, pin the version, read the reverse-share authorization code before exposing it to anyone, and expect to own the dependency updates yourself.

Frequently asked questions

Official sources

1. Issues
2. kyantech/Palmr on GitHub
3. License: Apache-2.0
4. README
5. Releases