Skip to content

Unofficial parody. The software is real. Unofficial parody of infloww.com. Not affiliated with Infloww. The software is real; the jokes are ours.

Inflowwww
Menu

Help center

Get Inflowwww running and run a team on it: Quick start, first login, sessions, security notes, updates and backups.

Setup and updates mean typing a few commands on a server. After that, everyone on the team works in a browser.

Who does what: the owner rents the server and invites the team; a technical friend runs the commands below, sets up the web address and locks it down (see Security notes), and zips the loginExtensionMulti folder for the owner to send to each creator; each creator captures their session (signs in to OnlyFans once in Chrome so the relay can act on the account) on a computer; each chatter signs in from an invite link.

If nobody on your team has done that before, ask someone who has, or read Who should stay on Infloww first.

Quick start

You need Docker Engine 25+ with Compose 2.20+. On Ubuntu 24.04, install it with Docker's own Ubuntu instructions; the distro's docker.io package may be older; check docker version. These are the steps from the README:

  1. Clone the repository (download the project's source folder) and cd into it.
  2. Create the external Docker network the app joins: docker network create n8n_default. (The network name comes from the maintainer's own Traefik setup; you don't need n8n.)
  3. Create the bind-mounted state files. They must be files, not directories.
  4. Write a .env with a share token and two session secrets.
  5. Start it.
git clone https://github.com/BlackPhoenixSlo/Opensoursed_infloww.git openinflowwww
cd openinflowwww

# openinflowwww-app joins the external network n8n_default; it must exist.
docker network create n8n_default

# Bind-mounted state files. They must exist as files, not directories.
echo '{"proxies": []}' > service/proxies.json
touch service/chatterly.db
mkdir -p service/sessions

# Compose reads .env beside docker-compose.yml. Nothing in it is strictly
# required: without SHARE_TOKEN the share-link gate is off (sign-in is the
# only gate), and without the session secrets every rebuild signs all users out.
cat > .env <<ENV
SHARE_TOKEN=$(openssl rand -hex 24)
SESSION_SECRET=$(openssl rand -hex 32)
CHATTER_SESSION_SECRET=$(openssl rand -hex 32)
ENV

docker compose up -d --build

Run this once. To update later, see Updating.

First login

A server usually has no browser, and the app listens on 127.0.0.1 only. From your own computer, forward the port with ssh -L 3001:127.0.0.1:3001 user@server, then open http://127.0.0.1:3001/?t=<SHARE_TOKEN> in your browser. grep SHARE_TOKEN .env on the server prints the token; it is remembered after the first visit. The first screen is Sign in / Register at /login: register the owner account there first, then add each OnlyFans account by capturing its session, then invite chatters. Ignore the installer link on the login screen; it points at an older setup.

Capture a session

Capturing a session means signing in to the creator's OnlyFans once, so the dashboard can use that login. The creator cannot paste it themselves: the Creators page is owner-only. They need Chrome on a computer, not a phone. They install the extension (open chrome://extensions, turn on Developer mode, click Load unpacked and pick the loginExtensionMulti folder the owner sends them), log in on onlyfans.com, open Messages, click Copy curl, and send the copied text to the owner over a channel they would trust with their password. The owner pastes it on the Creators page. No password is shared. The copied text is a live login to their account, so treat it like one.

In chrome://extensions it is listed as "Inflowwww Login Capture (OF + Fansly)"; the Creators page card calls it "Chatterly Login Capture". Both are old names of the same extension. On the Creators page, from a computer (the card is hidden on phones), ignore the Install Chrome Extension button, paste the copied text into the Paste cURL card and click Bootstrap from cURL.

The folder is loginExtensionMulti/ at the top of the repository. Its manifest asks Chrome for access to onlyfans.com and fansly.com only, and for permission to read those sites' cookies, see the open tabs, run its scripts on those sites, keep its own settings and write to the clipboard. Remove the extension after the capture.

The creator's account will be seen from the server's IP (or the proxy you assign) from then on; assign a proxy before pasting if that matters.

The desktop app's own capture button does not work against this relay today; use the Chrome extension. If a session stops working, capture it again the same way.

Reaching it from other machines

Both a public domain and a quick tunnel make the dashboard public. Read the security notes first: use a private network or a VPN, or a second login in front of it; the tunnel is for trying it only.

To give your chatters a normal web address, someone technical sets up a domain for the server once; the details are below.

127.0.0.1 only works on the server itself, or through your ssh -L tunnel. Your laptop, your phone and your chatters use the server's URL. The relay and the app bind to 127.0.0.1 on the host, and the app also joins the external n8n_default network with Traefik labels; if you run Traefik on that network it will be published.

One way is a domain behind a reverse proxy on the server: point Caddy or nginx at 127.0.0.1:3001, or use the Traefik labels in docker-compose.yml, which expect your own Traefik on the n8n_default network with a websecure entrypoint and a cert resolver named mytlschallenge. Put your host (in place of your-host.example.com) and those names in a docker-compose.override.yml, which the repository already ignores, so git pull stays clean; don't edit the tracked file. The other is the tunnel profile: docker compose --profile tunnel up -d starts a Cloudflare quick tunnel, docker compose logs openinflowwww-tunnel shows its trycloudflare.com URL, and the URL changes on every restart.

Security notes

In plain words: today anyone who can open your server's address can make an account on it, and a panel that restarts it needs no login. What the code does today:

  • Sign-up has no setting and needs no share token: anyone who reaches /login can register.
  • Any registered account can list every user and every creator account on the server.
  • The owner's and chatters' dashboard passwords are stored in plain text (service/auth.py). Creators' OnlyFans passwords never reach the server; the extension captures a session, not a password.
  • The lanes panel (the relay's rate-limit page at /lanes-panel) can change the relay's limits and restart it with no login.
  • ADMIN_PASSWORD alone unlocks "view as another user", transfer and delete: any signed-in account that knows it can use them on any user.

Run it only on a private network or over a VPN (WireGuard or Tailscale) until these are fixed. Putting basic auth in front of the whole relay breaks fans' tracking links (/t/) and the desktop app, so if you must expose it, protect everything except /t/ at your reverse proxy. All five are listed under Known gaps on the roadmap.

The passwords sit in service/chatterly.db and the proxy logins in service/proxies.json, so guard both like the sessions folder, and don't reuse a password from anywhere else.

Running a team

  • Logins are a share token for the dashboard plus per-user logins: the owner at /login, each chatter at /chatter-login. Chatters sign in with their own login; the share token is for the owner (it does not stop anyone from registering; see Security notes).
  • Invite each chatter from Employees > Manage employees > Chatters (/employees): under "Invite a new chatter", the "Mint invite URL" button makes a one-time /chatter-login?token=... link that expires after 24 hours, and they pick a username and password there.
  • Owner pages such as Creators, Vault Pro and Tracking links are hidden from chatters.
  • After signing in at /chatter-login, a chatter sees Dashboard, Messages Pro, Smart Messages, Scripts, Analytics and Settings for the creators they are linked to. In a chat they insert Scripts and attach media from the vault, limited to the folders the owner grants; a new chatter sees the whole vault until the owner picks folders.
  • Fan notes live in the fan insights rail in Messages Pro (/messages-pro).
  • Shifts live in Employees > Shift schedule (/employees/shifts); chatters clock in and out from the top bar.

Moving from Infloww? See Switch to Inflowwww.

Optional settings

  • ADMIN_PASSWORD: optional. It is the only check on the admin actions (view as another user, transfer or delete a user, set another agency's AI keys), so anyone signed in who knows it can use them on any account. If you set it, use a long random value (openssl rand -hex 32) in .env, then run docker compose up -d. Without it those actions are refused with a 503.
  • LLM keys (DEEPSEEK_API_KEY, DEEPINFRA_API_KEY, ZAI_API_KEY): the dashboard works without them.

Backups

The state lives in files next to the compose file. The service/ ones are bind-mounted into the relay; .env is read by Compose:

  • service/chatterly.db: the SQLite store.
  • service/sessions/: the captured sessions.
  • service/proxies.json: the proxy registry.
  • service/secrets/: the server keys and the admin password.
  • .env: the share token and the session secrets.
  • The vault image folders (service/vault_thumbs/, vault_posters/, vault_images/): once OnlyFans' signed URLs expire, those images can't be downloaded again.

The database runs in WAL mode inside the container, so do not just copy the file while the relay is running. Use SQLite's backup API from inside the container. From the install folder: 

mkdir -p backups
docker exec openinflowwww-relay python -c "import sqlite3; d = sqlite3.connect('/tmp/chatterly-backup.db'); sqlite3.connect('/app/service/chatterly.db').backup(d); d.close()"
docker cp openinflowwww-relay:/tmp/chatterly-backup.db backups/chatterly-$(date +%F).db
sudo tar czf backups/state-$(date +%F).tgz service/sessions service/proxies.json service/secrets service/vault_thumbs service/vault_posters service/vault_images .env

The relay runs as root and keeps the secrets file readable by root only, which is why tar needs sudo. chatterly.db and proxies.json hold passwords in plain text, so encrypt each archive before it leaves the server (with age or gpg) and keep the key somewhere other than the backup.

To test a backup, restore it to a scratch copy. Stock Debian and Ubuntu images don't ship the sqlite3 command, so install it once with sudo apt install sqlite3. 

mkdir -p restore-test
cp backups/chatterly-2026-10-12.db restore-test/chatterly.db
sqlite3 restore-test/chatterly.db "PRAGMA integrity_check;"   # prints: ok

A real restore means stopping the stack, putting the files back, and starting it again:

docker compose down
cp backups/chatterly-2026-10-12.db service/chatterly.db
sudo tar xzf backups/state-2026-10-12.tgz
docker compose up -d

docker compose down lets SQLite checkpoint and close cleanly. The compose file asks you to avoid docker kill for the same reason.

Updating

Back up first: service/chatterly.db, service/sessions/, service/proxies.json, service/secrets/, .env and the vault folders (service/vault_thumbs/, service/vault_posters/, service/vault_images/). Copy the database with the backup command above (sqlite3's backup API), not cp, while it runs. Then, from the install folder: 

git pull && docker compose up -d --build

Never re-paste the Quick start on a running install. From inside the install folder it clones a second copy into openinflowwww/openinflowwww and restarts the containers on that copy's empty database and new .env, so the dashboard comes back empty and everyone is signed out. Your data is still in the original folder: cd back to it and run docker compose up -d.

Docs in the repository

Still stuck?

Read the FAQ, check your containers on the status page, or open an issue. No SLA, no hold music, no desk.