TypeType did not ask to create admin account on first start

[hulmgulm]

I just installed TypeType with the install script, following the documentation. When docker compose up started all the containers, I opened the URL, but TypeType did not ask me to create an admin account.

Then I shut down TypeType and removed all docker volumes assigned to it.

After the restart, which recreated DB etc, the UI loads but still does not ask me to create an admin account.

I tried to create an account manually from the login screen but TypeType tells me that registrations are currently closed.

How can I create one now?

[Priveetee]

Mmmmm shit, okay, that’s not supposed to happen.

The first account created on an empty TypeType database should become the admin automatically, even when normal registrations are disabled.

If /register says registrations are closed, the backend currently thinks that a user already exists in PostgreSQL.

Before deleting anything again, can u run these from the TypeType install directory and send me the output?

docker compose exec postgres sh -lc \
  'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "SELECT id, email, role, created_at FROM users;"'

docker compose ls

docker volume ls --filter name=postgres_data

And can u also open this URL with your TypeType address?

http://YOUR_TYPETYPE_URL/api/auth/register/status

On an empty install it should return "bootstrapAvailable": true.

Don’t delete anything else for now, once I see the output I should be able to tell exactly what TypeType is detecting and how to fix it safely.

Also yeah, TypeType should directly send a fresh install to the admin account creation page. I’ll fix that part too :p

[hulmgulm]

Thank you for helping me.

Before deleting anything again, can u run these from the TypeType install directory and send me the output?

docker compose exec postgres sh -lc
'psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" -c "SELECT id, email, role, created_at FROM users;"'

 id | email | role | created_at
----+-------+------+------------
(0 rows)

docker compose ls

NAME                STATUS              CONFIG FILES
immich              running(8)          /home/xxx/docker/source/immich/docker-compose.yml
languagetool        running(2)          /home/xxx/docker/source/languagetool/docker-compose.yml
mariadb             running(2)          /home/xxx/docker/source/mariadb/docker-compose.yml
typetype-stack      running(7)          /home/xx/docker/source/typetype-stack/docker-compose.yml

docker volume ls --filter name=postgres_data

I changed PG to write its data to a host directory instead of a volume. ls of that directory is:

total 136
drwx------ 19 openmediavault-webgui docker                 4096 Jul 11 19:08 .
drwxrwsr-x  5 xxx               docker                 4096 Jul 11 18:33 ..
drwx------  7 openmediavault-webgui openmediavault-config  4096 Jul 11 18:42 base
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 19:08 global
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_commit_ts
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_dynshmem
-rw-------  1 openmediavault-webgui openmediavault-config  5743 Jul 11 18:42 pg_hba.conf
-rw-------  1 openmediavault-webgui openmediavault-config  2640 Jul 11 18:41 pg_ident.conf
drwx------  4 openmediavault-webgui openmediavault-config  4096 Jul 11 19:13 pg_logical
drwx------  4 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_multixact
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_notify
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_replslot
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_serial
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_snapshots
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:42 pg_stat
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_stat_tmp
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_subtrans
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_tblspc
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_twophase
-rw-------  1 openmediavault-webgui openmediavault-config     3 Jul 11 18:41 PG_VERSION
drwx------  4 openmediavault-webgui openmediavault-config  4096 Jul 11 18:49 pg_wal
drwx------  2 openmediavault-webgui openmediavault-config  4096 Jul 11 18:41 pg_xact
-rw-------  1 openmediavault-webgui openmediavault-config    88 Jul 11 18:41 postgresql.auto.conf
-rw-------  1 openmediavault-webgui openmediavault-config 30965 Jul 11 18:41 postgresql.conf
-rw-------  1 openmediavault-webgui openmediavault-config    36 Jul 11 19:08 postmaster.opts
-rw-------  1 openmediavault-webgui openmediavault-config    94 Jul 11 19:08 postmaster.pid

And can u also open this URL with your TypeType address?

http://YOUR_TYPETYPE_URL/api/auth/register/status

{"allowRegistration":true,"bootstrapAvailable":true,"localLoginEnabled":true}

On an empty install it should return "bootstrapAvailable": true.

Don’t delete anything else for now, once I see the output I should be able to tell exactly what TypeType is detecting and how to fix it safely.

Also yeah, TypeType should directly send a fresh install to the admin account creation page. I’ll fix that part too :p

[Priveetee]

Ahhh okay, that’s actually good news :p

Your database is empty and the API returns:

{"allowRegistration":true,"bootstrapAvailable":true,"localLoginEnabled":true}

So the backend is ready to create the first account, and that account will automatically become the admin.

Can u open this URL directly?

http://YOUR_TYPETYPE_URL/register

You should get the account creation form there.

If it still says registrations are closed, try one hard refresh on that page and send me a screenshot of exactly what it shows, because with the status response above it should not block registration.

The missing automatic redirect is definitely a frontend bug though. I already have the hot patch ready so fresh installs will directly open the admin registration page instead of leaving u on the normal UI.

[hulmgulm]

I can access register, but I get this error:

The backend answer:

backend log:

typetype-server-1      | 17:30:54.758 [eventLoopGroupProxy-7-3] INFO  Application - requestId=dc0a9bfd-d328-4818-b160-e21edcd84d5e method=GET path=/auth/register/status status=200 durationMs=3
typetype-1             | 172.23.0.1 - - [11/Jul/2026:17:30:54 +0000] "GET /api/auth/register/status HTTP/1.1" 200 93 "http://xxx:32110/register" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36" "-"
typetype-server-1      | 17:31:07.315 [eventLoopGroupProxy-7-1] INFO  Application - requestId=fbbd9fc6-0962-4e6f-ab3e-2792f431e60f method=POST path=/auth/register status=403 durationMs=1
typetype-1             | 172.23.0.1 - - [11/Jul/2026:17:31:07 +0000] "POST /api/auth/register HTTP/1.1" 403 0 "http://xxx:32110/register" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36" "-"
typetype-server-1      | 17:31:29.503 [eventLoopGroupProxy-7-2] INFO  Application - requestId=1e57d6ce-dd88-4748-a035-8911f23f1675 method=GET path=/auth/register status=405 durationMs=1

[Priveetee]

Well, we found the bouncer. The registration route itself is fine; Ktor is rejecting the browser origin before the request reaches it.

Your frontend is opened from http://xxx:32110, so that exact origin needs to be present in ALLOWED_ORIGINS in your .env file, without a trailing slash:

ALLOWED_ORIGINS=http://xxx:32110

If you already have other origins there, keep them and add this one separated by a comma. Then recreate the backend service so it receives the updated environment:

docker compose up -d --force-recreate typetype-server

After that, retry the form at /register. The GET /auth/register returning 405 is expected because that route only accepts POST; the important failure in your log is the empty 403 on the POST, which matches the CORS rejection.

I'll also make this error more explicit from now on. Thanks for the detailed report.

[hulmgulm]

One single character too mach. Easy to miss.

Thank you, that fixed the issue. I now have an admin user.

[hulmgulm]

Now I have a new issue. After logging out, I cannot login again. The backend responds with a 401 "invalid credentials".
Yes, I do remember the password I used. I first thought, that the password generated by my password manager is too long, so I deleted the PG again and created a user with password abc123 but I still cannot log in.

[Priveetee]

One quick check: are you trying to sign in with your email address or with your username?

[hulmgulm]

username

[hulmgulm]

It works with email

[Priveetee]

Ah, mystery solved. For now, use the email address you registered with to sign in. Username login is sneaking into the next version :)