Website · Documentation · Install · Features · Licence · Legal & privacy

Amfora

Self hosted file sharing. Send, receive and keep control.

Amfora is a self hosted workspace for sending and receiving files. Upload files to storage you control, turn them into a guarded share, or give someone a browser link where they can send files back without creating an account.

The workflow

1. Keep files in one workspace

Open My Files to upload files, create folders, and see what is stored. The workspace tracks uploads and makes the same files available when you create a share.

2. Send a controlled link

Select files and choose Create share. Give the share a name, then choose the restrictions that fit the handoff:

• password protection;
• expiration date;
• maximum views; and
• recipient email notifications.

Amfora creates an /s/<alias> link. Recipients open it in a browser and do not need an Amfora account. The owner can later edit the share, its files, and its restrictions.

3. Receive files from outside

Open Receive files, set optional file count, size, type, password, and expiration limits, then copy the /r/<alias> link. A sender uploads through the public page and can be asked for a name or email address. The owner reviews those uploads in Reverse shares, downloads them, or copies them into the workspace.

Product tour

The screenshots show the English interface with demonstration data.

The dashboard greets you, opens with Send files and Receive files, and shows storage, shares, downloads and files in one strip above the recent activity.

A share page is a statement column and a floating panel: who sent it, what is in it, and one button to download it all.

A receive link gives outside collaborators a simple upload form with the limits set by its owner.

The sign in screen supports password authentication, password recovery, and two factor authentication when it is enabled for the account.

What is in the box

Workspace	Files, folders, downloads and shares, with a dashboard for recent activity and storage usage.
Send files	Download links with optional passwords, expiry dates, view limits, recipient email notifications and QR codes.
Collect files	Upload requests with optional password, expiry, file count, size and type limits. Senders do not need an account.
Storage	Bundled MinIO or an external S3 compatible provider, on infrastructure you control.
Branding	Application name, description, logo, accent colour, font, corner radius and default language, all stored on the server. A brandpack removes the "Powered by Amfora" credit and unlocks a background image and custom CSS.
Access	User invitations, roles, deactivation, trusted devices and TOTP two factor authentication with backup codes. Optional OAuth2/OIDC sign in.

Make it yours

Everything a visitor sees reads the installation's name, logo and accent colour from the server, so every recipient sees the same brand on every device. The free version shows "Powered by Amfora" on the public pages. A brandpack is a signed key that removes that credit and unlocks a background image for the public pages and custom CSS. It is issued to one organisation, works on every installation that organisation runs, never expires, and is verified locally with an Ed25519 signature: nothing phones home. Paste it under Customization → Brandpack. Details for operators are in docs/BRANDPACK.md.

Install Amfora

You need Docker with Compose v2. The installer creates an amfora directory, writes a compose file pinned to the current release, pulls ghcr.io/solutionmax/amfora (amd64 and arm64) and starts it. It refuses existing installations and does not install Docker.

curl -fsSL https://amfora.solutionmax.net/get | sh

Open http://localhost:5487. On a new database, the first account created through the first run screen becomes the administrator. Later accounts are ordinary users unless an administrator invites or promotes them.

The compose file publishes the web interface on 5487 and bundled storage on 9379. The browser must be able to reach STORAGE_URL; the local example uses http://127.0.0.1:9379. The API listens on 3333 inside the container and is not published.

Prefer plain compose? Use docker-compose.yaml from this repository, which documents every option, and run docker compose up -d.

Build from source

curl -fsSL https://amfora.solutionmax.net/get | sh -s -- --source clones the release tag and builds it (Git, Bash and Buildx 0.30 or later). From a checkout:

make build TAG=local
AMFORA_IMAGE=amfora:local docker compose up -d

The dedicated builder reuses layers and bounds unused cache to a 4 GB target. make clean reclaims only build cache, preserving images and application data. See build and cache management.

Updating

Your files and settings live in the amfora_data volume; an update only replaces the image.

cd amfora
# set the new version in docker-compose.yaml, for example ghcr.io/solutionmax/amfora:2.0.1
docker compose pull
docker compose up -d

The admin area shows when a newer release is out. To have the host install signed releases for you, set up over the air updates once. Every release is listed on the releases page. Keep the previous image until the new one runs, so you can switch back.

Storage and deployment

The image includes a private MinIO storage service. You can use an external S3 compatible provider instead:

environment:
  ENABLE_S3: "true"
  STORAGE_URL: "https://files.example.com"
  S3_ENDPOINT: "s3.example.com"
  S3_ACCESS_KEY: "your-access-key"
  S3_SECRET_KEY: "your-secret-key"
  S3_BUCKET_NAME: "amfora-files"
  S3_USE_SSL: "true"

STORAGE_URL is the browser facing URL used for generated upload and download requests. Put both the app and that storage endpoint behind HTTPS, keep the API on the private container network, and set SECURE_SITE=true for secure cookies. Configure HSTS at the HTTPS reverse proxy.

The seeded workspace defaults to a 1 GiB maximum file size and 10 GiB maximum storage per user; an administrator can change those limits in Settings. See docker-compose.yaml and apps/server/.env.example for the complete configuration, including S3, proxy, CORS, and rate limit settings.

Amfora does not promise application level encryption at rest or end to end encryption. Protect the host or S3 account with the controls appropriate to the deployment. Passwords are stored as bcrypt hashes, and share passwords are sent in a request header rather than in a URL.

Administration

Administrators can invite and manage users, assign roles, configure storage and limits, customize the application, configure email, and enable authentication providers. The seeded provider choices are Google, Discord, GitHub, Auth0, Kinde, Zitadel, Authentik, Frontegg, and Pocket ID; additional compatible OIDC providers can be configured.

Each user can enable TOTP two factor authentication, download backup codes, and remove trusted devices. Password reset requires password authentication and a working SMTP configuration. Invite links are one time registration links.

Backups and upgrades

For bundled storage, back up the persistent /app/server directory, including prisma/amfora.db, minio-data, and the generated storage credentials. For external S3, back up the SQLite database and the S3 bucket according to the provider’s procedure. Keep the persistent volume when replacing the image; startup applies schema changes and seeds missing configuration/provider data.

Installations created under Palmr are migrated from prisma/palmr.db to prisma/amfora.db, while an existing internal bucket is preserved when no explicit bucket override is supplied. Verify a test share and download after an upgrade.

To recover a password from a trusted operator shell:

docker compose exec amfora sh -lc 'cd /app/amfora-app && ./reset-password.sh'

Use --list to list users. This tool bypasses normal account flows.

Development

cd apps/web && pnpm install && pnpm dev       # http://localhost:3000
cd apps/server && pnpm install && pnpm dev   # http://localhost:3333

Run server tests with cd apps/server && pnpm test. Before opening a change, the web checks pnpm format:check and pnpm type-check are useful alongside the repository’s normal build and lint commands.

Origins

Amfora began as a fork of Palmr, archived in February 2026, and has been developed independently since. Attribution and modification notices are in NOTICE.

Licence and attribution

Amfora is licensed under the Apache License 2.0; see LICENSE. The bundled minio and mc programs are separate, unmodified AGPL-3.0 programs redistributed with the image. See NOTICE and LICENSES/AGPL-3.0.txt for attribution and source information.

---

_{Amfora, a SolutionMAX product · Website · Documentation · Legal & privacy}

Support the work

Built and maintained by SolutionMAX. If Amfora helps your team, you can support the work.

Security configuration

Set APP_URL to the canonical browser origin (for example https://files.example.com) before enabling password reset email. Public deployments must use HTTPS for both app and storage and SECURE_SITE=true. The API binds to loopback inside the container by default; publish only the web and storage services through your TLS ingress.

Client supplied IP headers are ignored by default. Only behind an ingress that replaces incoming forwarding headers and blocks direct web access, set TRUST_CLIENT_IP_HEADERS=true for the web process and TRUST_PROXY=127.0.0.1,::1 for the API's known proxy hops. Never configure blanket trust of arbitrary proxies. Without this opt in, request rate limits conservatively share the proxy address; password failures are additionally limited per account.

Public upload clients must request a server generated temporary key with filename, extension and byte size, then register that same authorized upload. Registration checks storage and commits a private copy; old clients that choose arbitrary object keys must be updated. Two factor login now requires the challengeId returned by the password step; it expires after five minutes and is single use. Existing remembered devices must complete 2FA again to receive a secure random device cookie.