Self-Host Your Recipe Manager: Mealie and Tandoor Setup Guide

How the self-hosted architecture works

A self-hosted recipe manager is a web application running on hardware you control. That hardware might be a small home server, a network-attached storage device with supported container features, a virtual machine, or a 64-bit single-board computer that is compatible with the images published by the selected project.

Docker Compose describes the application containers, networks, persistent storage, and environment configuration. Mealie can be deployed with an application container and persistent application data, while larger deployments may use PostgreSQL. Tandoor deployments commonly include the application and PostgreSQL, with static and media handling determined by the current upstream deployment files. Do not assume that a hand-written reverse-proxy layout from an older tutorial still matches the current Tandoor release.

The local application listens on a host port. A browser on the same LAN connects directly to that local address. If you add Localtonet, the Localtonet client on the server establishes an outbound connection to one of our relay servers. A remote browser connects to the assigned public HTTPS address, the relay passes the request through that outbound connection, and the client forwards it to the local recipe manager.

We recommend proving the application locally before creating any public route. This separates application problems from tunneling problems and avoids exposing an incomplete installation.

Mealie vs. Tandoor: choose by workflow, not a feature-count snapshot

Both projects evolve over time, so version numbers, menu paths, integrations, import compatibility, mobile behavior, and deployment files can change. A comparison should therefore focus on durable architectural differences and on features you confirm in the release you intend to install.

Choose Mealie when operational simplicity is your priority

Mealie is a practical candidate when you want a focused recipe interface and prefer the simplest deployment supported by the current release. It is still important to inspect the upstream Compose file rather than assuming that a single-container example from an older article remains complete.

Choose Tandoor when its current planning model fits your household

Tandoor is a strong candidate when you prefer its recipe organization and meal-planning model and are comfortable operating PostgreSQL. Database migrations, static assets, uploaded media, proxy settings, and trusted origins all need to follow the current project documentation.

Test uncertain features before committing

Create a temporary local deployment and test the workflows that actually matter to you. Import several representative recipe pages, edit ingredient units, build a shopping list, invite a non-administrator user, upload images, and try the interface on the phone and browser you intend to use. No importer can reliably extract every recipe website because page structures and access controls differ.

Prerequisites and deployment planning

Prepare the host before downloading either project. This guide assumes a Linux-style shell for examples, but Docker Desktop and other supported Docker environments can also run Compose projects. Commands and filesystem ownership behavior can differ by operating system.

Host requirements

• A supported 64-bit operating system and processor architecture for the exact images you select.
• Docker Engine or Docker Desktop with the Compose plugin.
• Enough storage for the database, recipe images, application updates, and multiple backup generations.
• A fixed local address or stable local hostname if other LAN devices will connect directly.
• Administrative access for initial directory creation and any ownership corrections.
• A second storage location for backups. A backup on the same disk is not protection against disk failure.
• A Localtonet account and client only if remote access is required.

Resource requirements depend on image architecture, database size, import activity, background jobs, and release. Avoid relying on an uncited memory figure from a blog post. Observe the actual containers after importing representative data.

Verify Docker and Compose

docker version
docker compose version
docker info

All three commands should complete without an unexpected daemon connection or permission error. If your account cannot access Docker, follow your platform's Docker installation guidance. Do not weaken socket permissions as a shortcut. Membership in a Docker administration group can grant extensive control over the host and should be treated accordingly.

Create an isolated project directory

Keep each application in its own directory. This prevents similarly named environment files and Compose projects from colliding.

mkdir -p "$HOME/recipe-app"
cd "$HOME/recipe-app"
umask 077
touch .env
chmod 600 .env

Add secret-bearing files and local data directories to your source-control ignore rules. Do not commit the environment file, database dumps, uploaded media, or generated backups.

.env
backups/
data/
media/
postgres-data/

Generate secrets without embedding them in Compose

Generate independent credentials for the application administrator, database account, and framework secret where the selected deployment requires them. Do not reuse a personal email password or another service's database password.

openssl rand -hex 32
openssl rand -base64 48

Store the generated values in the protected .env file or in a secrets manager supported by your environment. Do not paste real secrets into shell commands that will remain in history, issue trackers, screenshots, or chat messages.

Select and record an exact release

Do not use a floating latest tag for a reproducible installation. Choose a published application release, download the deployment files associated with that release, and record both the release tag and image digest. A tag identifies the intended release, while a digest prevents the referenced image content from changing unexpectedly.

The exact current tags and digests are intentionally not hardcoded here because they are time-sensitive. Obtain them from the release you have reviewed. Your maintenance record should include the application release, database image release, deployment-file revision, installation date, and the location of the pre-update backup.

Deploy Mealie or Tandoor from version-pinned upstream files

The safe deployment pattern is the same for both applications: obtain the Compose files belonging to a specific upstream release, inspect them locally, replace floating image references with reviewed release references, configure secrets through a protected environment file, validate the rendered configuration, and then start the project.

Mealie deployment workflow

docker compose config
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200

Tandoor deployment workflow

docker compose config
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200

If the upstream deployment defines health checks, wait until required services report healthy. If it does not, use application logs and an HTTP request to the local port. Avoid inventing a health endpoint that the release may not provide.

Initialize the application and verify local operation

Initialization should happen before public exposure. The exact first-run screen and administrator workflow are release-dependent, so follow the prompts displayed by the installed application rather than relying on an old menu path.

Confirm the containers and local port

docker compose ps
docker compose logs --tail=200

Check that expected services remain running, the database is not repeatedly restarting, and there are no permission, migration, connection, or missing-secret errors.

Open the local address shown by the reviewed Compose configuration. From the host, an HTTP header check is also useful:

curl -I http://127.0.0.1:YOUR_LOCAL_PORT/

Replace YOUR_LOCAL_PORT with the host port in your own configuration. A redirect to a login or setup page can be normal. A connection refusal means nothing is listening at that address. A gateway error generally means a frontend component cannot reach the application.

Create the administrator safely

• Use a unique, randomly generated password.
• Do not reuse the database password for the administrator.
• Disable or leave disabled open registration unless intentionally required.
• Create ordinary household accounts for routine use instead of sharing the administrator account.
• Review role and group behavior in the installed release before inviting users.

Run a functional acceptance test

Before adding real data, create a temporary recipe manually. Upload an image, edit ingredients, add the recipe to a meal plan or shopping workflow, sign out, and sign back in. Restart the Compose project and confirm the test data remains present.

docker compose restart
docker compose ps
docker compose logs --tail=100

Next, test recipe import with a page you are permitted to access. Review the imported title, ingredient quantities, units, instructions, and image. Importers depend on source-page markup and can make mistakes. Imported recipes should be treated as drafts until reviewed.

Expose Mealie or Tandoor with a Localtonet HTTP tunnel

Once the recipe manager works locally, an HTTP tunnel can make it available through a public HTTPS address. With Localtonet, the client opens an outbound connection to our relay infrastructure. This works without inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

Do not place an authentication token in a published command, Compose file, screenshot, or shell-history example. A Localtonet device AuthToken identifies the client device and must be kept private.

For the maintained product workflow, see the Localtonet HTTP tunnel documentation. The dashboard is the authority for current Process Type, relay, subdomain, custom-domain, and plan availability.

Configure public-origin and proxy settings carefully

Some application releases require a public base URL, allowed host, trusted origin, or proxy-aware setting. Use only the variable names documented for the exact installed release. For Tandoor, Django host and CSRF protections must not be disabled as a shortcut. Add only the assigned public HTTPS origin through the documented configuration.

After changing an environment value, render the Compose configuration again and recreate affected containers:

docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100

Retest login, logout, forms, image uploads, and recipe edits through the public address. A page loading successfully does not prove that POST requests or CSRF validation work.

Security checklist for an internet-reachable recipe manager

Also minimize host exposure. Publish only the application port required for local access. Do not publish PostgreSQL to the internet. Do not expose Docker's control socket to the application containers unless the official architecture explicitly requires it and you understand the privilege implications.

Protect the host itself with supported operating-system updates, restricted administrative access, and a firewall appropriate to the environment. Review container logs for repeated login failures and unexpected requests, but do not place passwords, tokens, or imported private data into publicly shared log excerpts.

Routine operation, updates, and rollback

Inspect status and logs

docker compose ps
docker compose logs --tail=200
docker compose logs --since=30m

For a specific component, append its Compose service name. Discover exact service names from the current project rather than assuming names from another tutorial:

docker compose config --services

Monitor storage and container behavior

docker system df
docker stats --no-stream

These commands help identify disk growth and current resource consumption. Do not delete volumes or run broad Docker cleanup commands while diagnosing storage pressure. A volume may contain the only database or uploaded-media copy.

Use a controlled update procedure

docker compose config
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200

Plan rollback before updating

Rolling back an image is not always sufficient after a database migration. If the new release changes the schema incompatibly, restore the complete pre-update database and media or application-data backup together, then start the previously recorded image references.

Stop the Localtonet tunnel during a failed upgrade or restore. This prevents users from writing new data while you are returning the application to a consistent point in time.

Complete backup and restore workflows

Backups need three properties: completeness, separation from the live host, and a tested restore procedure. Schedule them often enough that the amount of acceptable data loss matches your household's use. Keep multiple generations so corruption or accidental deletion is not copied over the only good backup.

Mealie with application-managed local data

If the selected Mealie deployment stores its complete state in one documented persistent application-data mount, a cold filesystem backup is straightforward. Stop the application to avoid copying a database while it is being written.

mkdir -p backups
docker compose stop
tar -czf "backups/mealie-data-$(date +%Y%m%d-%H%M%S).tar.gz" ./YOUR_MEALIE_DATA_DIRECTORY
docker compose start
docker compose ps

Replace the placeholder with the bind-mounted directory from your reviewed Compose file. If the deployment uses a named Docker volume, use a documented volume backup method or change to a clearly managed bind mount before relying on this command.

Restore Mealie local data

1. Stop the Localtonet tunnel.
2. Stop the Compose project.
3. Move the current data directory aside rather than deleting it.
4. Extract the selected archive into the original parent directory.
5. Restore the original ownership and permissions recorded during installation.
6. Start the same pinned Mealie release used when the backup was created.
7. Verify local login, recipes, images, and settings before restarting remote access.

docker compose down
mv ./YOUR_MEALIE_DATA_DIRECTORY ./YOUR_MEALIE_DATA_DIRECTORY.before-restore
tar -xzf backups/YOUR_SELECTED_MEALIE_BACKUP.tar.gz
docker compose up -d
docker compose ps
docker compose logs --tail=200

Mealie with PostgreSQL

A PostgreSQL deployment requires a database dump plus any separate application-data or media mount defined by the selected release. Discover the database service name with docker compose config --services.

DB_SERVICE="YOUR_DATABASE_SERVICE"
mkdir -p backups
docker compose exec -T "$DB_SERVICE" sh -c \
  'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  > "backups/mealie-db-$(date +%Y%m%d-%H%M%S).sql"

Back up the persistent application files separately. Keep the SQL dump and matching file archive under the same timestamp or backup identifier.

Tandoor backup

A complete Tandoor backup must include PostgreSQL and uploaded media. Also retain the Compose file, image references, and required configuration so the environment can be reconstructed.

DB_SERVICE="YOUR_DATABASE_SERVICE"
mkdir -p backups

docker compose exec -T "$DB_SERVICE" sh -c \
  'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  > "backups/tandoor-db-$(date +%Y%m%d-%H%M%S).sql"

tar -czf "backups/tandoor-media-$(date +%Y%m%d-%H%M%S).tar.gz" \
  ./YOUR_TANDOOR_MEDIA_DIRECTORY

Use the service and media-directory names from the exact upstream deployment. If uploaded content is stored in a named volume, back up that volume rather than assuming a host directory.

Restore a PostgreSQL-based deployment

Restore into an empty database that matches the database major version expected by the backed-up release. The following sequence is intentionally expressed with placeholders because service and database names belong to your reviewed deployment.

DB_SERVICE="YOUR_DATABASE_SERVICE"

docker compose down
mv ./YOUR_MEDIA_DIRECTORY ./YOUR_MEDIA_DIRECTORY.before-restore
tar -xzf backups/YOUR_SELECTED_MEDIA_BACKUP.tar.gz

docker compose up -d "$DB_SERVICE"
docker compose exec -T "$DB_SERVICE" sh -c \
  'dropdb -U "$POSTGRES_USER" --if-exists "$POSTGRES_DB" &&
   createdb -U "$POSTGRES_USER" "$POSTGRES_DB"'

docker compose exec -T "$DB_SERVICE" sh -c \
  'psql -U "$POSTGRES_USER" "$POSTGRES_DB"' \
  < backups/YOUR_SELECTED_DATABASE_BACKUP.sql

docker compose up -d
docker compose ps
docker compose logs --tail=200

Test restores regularly

A successful archive command does not prove recoverability. Periodically restore a backup to an isolated Compose project with different local ports. Confirm that users, recipes, images, meal plans, and settings are present. Record the test date and any corrections needed.

Troubleshooting without destroying data

Check directory ownership without guessing

Permission errors often occur when the container runs as a different user from the host directory owner. First inspect the upstream image documentation and current container configuration. Do not recursively assign world-writable permissions. Record working ownership and modes so they can be restored after moving data.

ls -la
docker compose config
docker compose ps
docker compose logs --tail=200

Do not delete data to reset a password or fix startup

Removing a database volume or application-data directory destroys recipes and accounts. Use the password-reset or administrator-recovery procedure documented for the exact application release. Create a complete backup before running any management command that changes users, migrations, or database state.

Frequently asked questions