What to do inside each app once it is running.

Documents and PDFs

First-run steps, grouped by job. Every app here is running at this point. This page is about what to do inside it.

Stirling-PDF

1. Open it and confirm the tool list loads. If the page appears but tools are missing, check the logs rather than reloading.
2. Decide about accounts. Login is off by default. Turning it on gives you users and API keys; single sign-on is in the paid tier, so if you need Stirling behind a login without paying, put a forward-auth gateway in front instead.
3. If you want OCR, add the language data. Only English ships by default, and OCR silently produces poor results rather than failing when the language pack is missing.

BentoPDF

Nothing to configure. There are no accounts and no server-side settings, because there is no server-side processing. Open it and use it.

PdfDing

1. Create the first account. It becomes the admin.
2. Turn off open registration unless you want it. Otherwise anyone who can reach the page can sign up.
3. Point the consume directory somewhere useful if you want to add files without the UI.
4. Set up OIDC now if you are going to. It is included rather than paid for, and retrofitting it after people have local accounts is more work.

Document archives

Paperless-ngx

1. Create the superuser. Depending on how you deployed, this is either a prompt on first run or a one-off command against the container.
2. Confirm the consume directory works before anything else. Drop one PDF in and watch the logs. If it is not picked up, nothing later matters.
3. Set your document language under settings, so OCR is not guessing at English.
4. Create three or four tags and two correspondents by hand, then let the classifier learn from your corrections. It gets better with use and worse with a hundred tags created up front.
5. Add Gotenberg and Tika only if you need office documents. They are two more containers and most people only ever feed it PDFs and scans.

Docspell

1. Register the first account, then create a collective. Documents belong to the collective rather than the user, which is the model that confuses people coming from Paperless.
2. Check that joex is actually running. The web UI comes up perfectly well without it and simply never processes anything, which looks like a stuck queue rather than a missing service.
3. Confirm Solr is reachable before you rely on full-text search. Search fails quietly rather than erroring.

Notes and wikis

BookStack

1. Log in as admin@admin.com with the password password, then change both immediately. This is the single most common way a self-hosted BookStack ends up compromised.
2. Check that APP_URL matches the address you actually use. If links and redirects send you to the wrong host, this is why.
3. Set the default visibility for new content before inviting anyone.
4. Turn off public registration unless you want it.

Wiki.js

1. Complete the setup wizard, which creates the admin account and the initial configuration.
2. Pick a storage target. Git synchronisation is the reason many people choose Wiki.js, and setting it up on day one is much easier than migrating content into it later.
3. Confirm your image tag is pinned to :2 and not latest, before you have content worth losing.

Obsidian and Calligra

Mount your vault or documents directory explicitly. Anything written outside a mounted path lives inside the container and disappears on the next update. Expect a self-signed certificate warning on port 3001; that is normal and is why the HTTP port exists for proxied setups.

Kiwix

1. Download ZIM files into the mounted data directory. Check sizes on the Kiwix download site first, because a full Wikipedia with images is a very different proposition from the no-pictures build.
2. Restart the container after adding files. The command argument is evaluated at start, so new files do not appear on their own.

Code forges

Forgejo

1. Complete the installer page. This is where the database connection and the site URL are set, and the site URL is the value that ends up in every clone command you copy.
2. Set the SSH port to the host port you published, not 22, unless you moved your host's own SSH daemon out of the way.
3. Disable open registration unless you want it. The installer has a checkbox for it and it is easy to skip past.
4. Create the first user. The first registered account becomes the administrator.
5. If you want Actions, enable the runner separately. Forgejo ships the CI feature; the runner is its own component.

Gogs

1. Work through the web installer. Choose SQLite unless you have a reason not to.
2. Set the SSH port to your published host port. This is the field people miss, and the symptom is clone URLs that look right and do not work.
3. Set the application URL to the address you actually use.
4. Create the admin account in the installer rather than leaving it to the first registration.

File transfer

PairDrop

Open it on two devices on the same network. They should see each other within a second or two. If they do not, the problem is almost always one of two things: the devices are on different subnets or VLANs, or something is blocking WebRTC.

Leave DEBUG_MODE off in normal use. Upstream says not to use it in production because it logs client IP addresses.

PsiTransfer

1. Before the first start, run chown -R 1000 ./data. Upstream requires the data volume to be owned by UID 1000, and the failure without it is a permission error that does not name the cause.
2. Set PSITRANSFER_ADMIN_PASS if you want the /admin page. It is disabled entirely until you do.
3. Set PSITRANSFER_UPLOAD_PASS if the instance is reachable by anyone you do not know. Otherwise it is an open upload endpoint.
4. Choose a default retention. The point of this tool is that files leave again.

Zipline

1. Generate CORE_SECRET longer than 32 characters. Shorter values are rejected outright. Quote it in the compose file so special characters survive.
2. Create the first user, which becomes the administrator.
3. Generate an API token and paste it into ShareX or Flameshot. This is the only reason most people run Zipline.
4. Set upload size limits before sharing the instance.

Coming from version 3, use the built-in importer. There is no in-place upgrade, and several variables were renamed, so an old compose file fails in ways that do not point at the cause.

Chibisafe

1. Create the database, uploads and logs directories by hand before the first start, or you get permission errors.
2. Decide which upstream layout you are following, the split three-service one from the repository or the single container from Docker Hub, and follow it all the way through. The volume paths differ between them.
3. Change the admin password immediately.
4. Turn off public registration unless you want it.

Boards and workspaces

CryptPad

1. Set both CPAD_MAIN_DOMAIN and CPAD_SANDBOX_DOMAIN to genuinely different origins, and point both at the instance through your reverse proxy.
2. Register the first account, then claim admin rights by adding its public key to the admin list in the configuration. The first account is not automatically an administrator.
3. Decide on registration and quotas before sharing the address.

Wekan

1. Set ROOT_URL to the external address you actually use, including the scheme. Wrong values here break logins and invite links in ways that look like authentication bugs.
2. Create the first account, which becomes the administrator, then disable registration.
3. Import from Trello if you are migrating. Export a board to JSON afterwards to confirm your exit route works.

AppFlowy and Huly

Both are deployed from their own repositories with their own scripts, so their setup is upstream's to document rather than this site's. Two things are worth knowing before you start.

• Huly needs 8GB of RAM as a floor and upstream warns that smaller servers may fail outright. Check what you have before you spend an evening on it. Upgrades from 0.6 to 0.7 need dedicated migration steps.
• AppFlowy expects a real domain, because the desktop and mobile clients connect to a base URL and a websocket URL that both have to resolve. The web experience is secondary to the apps.

OpenSign

1. Configure SMTP in .env.prod before creating accounts. Without a working mail adapter, verification and password resets fail with an unhelpful error.
2. Replace MASTER_KEY with your own value. Upstream describes it as the key that allows access to all the data.
3. Replace the sample signing certificate in PFX_BASE64 with a real one before signing anything you care about.
4. Leave PARSE_MOUNT at /app. Upstream says not to change it.

Jitsi Meet

1. Download and extract the latest release. Upstream says explicitly not to clone the repository.
2. Copy env.example to .env, then run the project's gen-passwords.sh. It writes every required secret for you. Do not invent these; the components have to agree on them.
3. Create the config directories before the first start, using the mkdir line from upstream's guide.
4. Set PUBLIC_URL to your real domain.
5. Open 10000/udp, and 4443/tcp for clients whose networks block UDP.

Dashboards

Homarr

1. Generate SECRET_ENCRYPTION_KEY with openssl rand -hex 32 and store it somewhere you will still have it in a year.
2. Create the admin account on first load.
3. Add the Docker integration only if you want container status, and mount the socket read only if you do.
4. Build the board, then export a backup. The layout lives in Homarr's database rather than in a file you already back up.

Dashy

1. Mount a directory at /app/user-data containing conf.yml. Not a single file at /app/public/conf.yml, which is where version 2 kept it and where older guides still point.
2. Publish against container port 8080, not 80. That changed in version 3 so the image could run as non-root.
3. Build the dashboard in the UI editor if you prefer, then save the file and commit it.
4. Turn on status checks for the tiles you care about.