when setting PANGOLIN_SETUP_TOKEN on initial server start server crashes
Overwriting existing token in DB since PANGOLIN_SETUP_TOKEN is set
Failed to ensure setup token: TypeError: Cannot read properties of undefined (reading 'tokenId')
at ensureSetupToken (/app/server/setup/ensureSetupToken.ts:75:66)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
at async runSetupFunctions (/app/server/setup/index.ts:10:5)
at async startServers (/app/server/index.ts:35:5)
TypeError: Cannot read properties of undefined (reading 'tokenId')
at ensureSetupToken (/app/server/setup/ensureSetupToken.ts:75:66)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
at async runSetupFunctions (/app/server/setup/index.ts:10:5)
at async startServers (/app/server/index.ts:35:5)
Running following sql query and restarting the service fixes it:
So the env variable is either not intended to be used on first start or there is a logic error.
Environment
OS Type & Version: (e.g., Ubuntu 22.04)
Pangolin Version: postgresql-1.15.1
Gerbil Version: NONE
Traefik Version: UNRELATED
Newt Version: UNRELATED
Olm Version: (if applicable) UNRELATED
To Reproduce
Start a fresh service on an empty DB injecting some valid PANGOLIN_SETUP_TOKEN into env.
Expected Behavior
I don't know. I personally would expect that token to be pushed into the database and thats it.
Also a bit straingh to hold it into the DB if you ever need one and don't want to keep it around ?
Wouldn't it be easier just read it from env, or generate it if user table or what ever is empty and then forget about it?
Originally created by @8de2fdb0 on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2361
### Describe the Bug
when setting PANGOLIN_SETUP_TOKEN on initial server start server crashes
```bash
Overwriting existing token in DB since PANGOLIN_SETUP_TOKEN is set
Failed to ensure setup token: TypeError: Cannot read properties of undefined (reading 'tokenId')
at ensureSetupToken (/app/server/setup/ensureSetupToken.ts:75:66)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
at async runSetupFunctions (/app/server/setup/index.ts:10:5)
at async startServers (/app/server/index.ts:35:5)
TypeError: Cannot read properties of undefined (reading 'tokenId')
at ensureSetupToken (/app/server/setup/ensureSetupToken.ts:75:66)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
at async runSetupFunctions (/app/server/setup/index.ts:10:5)
at async startServers (/app/server/index.ts:35:5)
```
Running following sql query and restarting the service fixes it:
```sql
insert into "setupTokens" values ('8afa9ce2e0866e4','initialDataBaseToken', false, extract(epoch from now())::bigint::text, null);
```
So the env variable is either not intended to be used on first start or there is a logic error.
### Environment
- OS Type & Version: (e.g., Ubuntu 22.04)
- Pangolin Version: postgresql-1.15.1
- Gerbil Version: NONE
- Traefik Version: UNRELATED
- Newt Version: UNRELATED
- Olm Version: (if applicable) UNRELATED
### To Reproduce
Start a fresh service on an empty DB injecting some valid PANGOLIN_SETUP_TOKEN into env.
### Expected Behavior
I don't know. I personally would expect that token to be pushed into the database and thats it.
Also a bit straingh to hold it into the DB if you ever need one and don't want to keep it around ?
Wouldn't it be easier just read it from env, or generate it if user table or what ever is empty and then forget about it?
@oschwartz10612 so i guess the answer is that PANGOLIN_SETUP_TOKEN is not intended to be used to be injected on startup
Since now it will only be used if you start the service once to generate the db token, then restart it again.
Makes it really hard to manage this in an automated environment.
<!-- gh-comment-id:3815404409 -->
@8de2fdb0 commented on GitHub (Jan 29, 2026):
@oschwartz10612 so i guess the answer is that PANGOLIN_SETUP_TOKEN is not intended to be used to be injected on startup
Since now it will only be used if you start the service once to generate the db token, then restart it again.
Makes it really hard to manage this in an automated environment.
@oschwartz10612 commented on GitHub (Jan 29, 2026):
In the above commit I fixed this issue. It will be rolled out in the next release so you can use the environment variable on startup.
<!-- gh-comment-id:3815530366 -->
@oschwartz10612 commented on GitHub (Jan 29, 2026):
In the above commit I fixed this issue. It will be rolled out in the next release so you can use the environment variable on startup.
@oschwartz10612 sorry you are right, i read the code wrong, thanks a lot.
By the way is there any remote possibility to get an env variable that can inject a API token during initial bootstrapping.
I would like to drive pangolin complete via API, I think the only hurdle is that it would need a kind of service account, which the initial token is related too.
I can also offer to implement that if it would make it on the features list.
<!-- gh-comment-id:3815553917 -->
@8de2fdb0 commented on GitHub (Jan 29, 2026):
@oschwartz10612 sorry you are right, i read the code wrong, thanks a lot.
By the way is there any remote possibility to get an env variable that can inject a API token during initial bootstrapping.
I would like to drive pangolin complete via API, I think the only hurdle is that it would need a kind of service account, which the initial token is related too.
I can also offer to implement that if it would make it on the features list.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @8de2fdb0 on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2361
Describe the Bug
when setting PANGOLIN_SETUP_TOKEN on initial server start server crashes
Running following sql query and restarting the service fixes it:
So the env variable is either not intended to be used on first start or there is a logic error.
Environment
To Reproduce
Start a fresh service on an empty DB injecting some valid PANGOLIN_SETUP_TOKEN into env.
Expected Behavior
I don't know. I personally would expect that token to be pushed into the database and thats it.
Also a bit straingh to hold it into the DB if you ever need one and don't want to keep it around ?
Wouldn't it be easier just read it from env, or generate it if user table or what ever is empty and then forget about it?
@8de2fdb0 commented on GitHub (Jan 29, 2026):
@oschwartz10612 so i guess the answer is that PANGOLIN_SETUP_TOKEN is not intended to be used to be injected on startup
Since now it will only be used if you start the service once to generate the db token, then restart it again.
Makes it really hard to manage this in an automated environment.
@oschwartz10612 commented on GitHub (Jan 29, 2026):
In the above commit I fixed this issue. It will be rolled out in the next release so you can use the environment variable on startup.
@8de2fdb0 commented on GitHub (Jan 29, 2026):
@oschwartz10612 sorry you are right, i read the code wrong, thanks a lot.
By the way is there any remote possibility to get an env variable that can inject a API token during initial bootstrapping.
I would like to drive pangolin complete via API, I think the only hurdle is that it would need a kind of service account, which the initial token is related too.
I can also offer to implement that if it would make it on the features list.