THE VISUAL GUIDE · PAGE 1 OF 3

One app.
A few clear jobs.

Start here. Follow the arrows to see who uses ComfyAuth, where it runs, and how the pieces fit together.

First, meet the two different people.

</>

The developer

You build an app. You sign in to ComfyAuth’s website to create a project and manage its users.

☺

Your app’s user

Someone uses your app. They sign in on the screens you build. They do not need a ComfyAuth developer account.

Think of ComfyAuth as the person checking tickets at the door. Your app still decides which rooms a person can enter.

The whole system, in one picture.

Where everything lives

YOUR APPLICATION · ANY HOST, ANY LANGUAGE

Your login screen
The page your user sees. You design it.
Your app’s backend
The part of your app that talks to ComfyAuth and keeps browser session tokens private.

↓ HTTPS + JSON = a secure web request with ordinary data

VERCEL · ONE GO APPLICATION

Website + portal
Product pages, developer login, project dashboard.
API doors
Small web addresses for signup, login, users, and projects.
Authentication rules
Check passwords, confirm ownership, create or end sessions.

These are parts of the same application, not three separate servers. The portal and your app enter through different API doors.

↓ Read and save records

▤

Neon / PostgreSQL

The organised filing cabinet: projects, users, password hashes, sessions, and queued email.

↓ Deliver queued messages

✉

Hostinger email → inbox

Sends verification and reset links over an encrypted connection.

EMAIL CONNECTED

Right now: the website, API, and databases are deployed. Hostinger email is connected. Verification and password-reset emails have been tested in our Hostinger inbox; delivery to other email providers and reliable idle retries still need testing and setup.

What happens when you click a button?

A request moves through four small jobs.

1 · Ask
Your page sends a request: “Please log me in.”
2 · Check the request
The HTTP layer checks the format, request limits, and the correct project.
3 · Apply the rules
The auth layer checks the password and account, then uses the database.
4 · Reply
Your app receives a result and decides which screen to show.

A failed check returns an error. A successful login does not automatically grant permission to everything in your app.

Show me the code behind those boxes.

cmd/api/main.go↓ starts the Vercel serverinternal/httpapi/api.go · portal.go↓ validates the request and selects the operationinternal/auth/service.go · portal.go · crypto.go↓ applies account, ownership, and password rulesinternal/database/database.go → PostgreSQL

internal/config/config.go reads settings. internal/httpapi/web/ contains the HTML, CSS, and JavaScript you see. On a persistent host, cmd/comfyauth/main.go starts the same service and an email worker.

How code gets onto Vercel.

Build first. Publish only if the checks pass.

Source files
The Go code and website files are uploaded.
Build + tests
Verify dependencies; run checks and race tests against a separate test database.
Deploy
Vercel builds the Go server and serves the embedded website.

The runtime database is for real app data. The separate test database is for disposable test records. Schema changes are applied separately with operator credentials.

A tiny dictionary — no jargon required.

API: A set of doors other software can knock on.
Backend: Code running on a server, away from the browser.
Database: Organised, saved records that survive a restart.
Project: One separate application inside ComfyAuth.
Session: A temporary login pass that can expire or be cancelled.

One app.A few clear jobs.