Uptime Robot (An Easy one to get started)

[bmschwa]

Hi All,

Was trying to get some experience using windmill & hoped sending up the Uptime Robot (from @tristan795?) would be a super easy way to get started. I am using the same database as windmill in order to limit the configuration and complexity... nonetheless couldn't get past this confirmation step... any suggestions?

[identity-wael]

The useful clue is the final error in your screenshot:

(ENOIDENTIFIER) no tenant identifier provided (external_id or sni_hostname required)

The earlier database connection and grants succeeded; the failure is when Windmill tests the connection used to store the app's data. That points to database/pooler routing rather than the Uptime Robot app itself.

Are you using a Supabase/shared-pooler URL for the instance database? Supabase's connection documentation uses a project-qualified username for its shared pooler. Windmill's custom instance database setup creates a separate custom_instance_user for these databases instead of reusing the original DATABASE_URL user. If that new connection uses a shared pooler without the tenant identifier, the original connection can work while this check fails.

Check whether the failing connection uses the provider's direct PostgreSQL endpoint or its shared pooler, and whether the generated username retains the required tenant routing information. A direct endpoint, where supported and reachable, removes that particular shared-pooler requirement; it does not by itself guarantee that the provider allows all of Windmill's database/role operations.

Please share your Windmill version, database provider, and direct-vs-pooled connection type, with credentials and project identifiers removed. I would not reset passwords or keep retrying grants based on this error: it specifically says the connection cannot identify its tenant.

[bmschwa]

Thanks so much for getting back to me, Wael.

Indeed, I am using supabase ... their free tier! As I understood from the supabase documentation, because I'm on the free tier & didn't want to buy the addon, connecting directly was only through ipv6. Since I need to use ipv4, I am using the "Shared pooler in Session Mode".

And you're right; the original set up in the shared mode seems to work.

I am on Windmill version CE v1.817.0-7-g318f89960e

Do I just need to figure out how to use ipv6 if I want to use the free tier of supabase?

Thanks again

[jmrplens]

Not necessarily. IPv6 (or a paid plan) is only needed for the "Windmill database" option; the app's data table can still live on your free Supabase project through the same session pooler you use now.

The reason is how the pooler routes. Supavisor finds your project from the login name, postgres.<project_ref>, which is why your DATABASE_URL works. The "Windmill database" option creates databases next to Windmill's own and logs in to them as its own role, custom_instance_user, without the project suffix, so the pooler cannot tell which project the connection is for: that is the ENOIDENTIFIER. Windmill now checks this during the setup and says so directly (#11244, in v1.816.0 and later).

So, in order of effort:

• "Your own database", over IPv4 and free. In the data table setup pick "Your own database" instead of "Windmill database", and paste the Session pooler connection string from Supabase's Connect dialog (user postgres.<project_ref>, port 5432). That login carries the project suffix, so the pooler routes it, and it is the mode Windmill's own Supabase integration recommends ("Reaches Supabase over IPv4. Works from any worker."). One caution: scripts using that data table connect with that login, and postgres on the same database Windmill itself lives in can also read Windmill's tables. A second Supabase project (the free tier allows two) or a dedicated role is the safer home for it.

• "Windmill database" over IPv6. Point DATABASE_URL at the direct endpoint, postgres://postgres:<password>@db.<project_ref>.supabase.co:5432/postgres. The user there is plain postgres, and it is the same database, so nothing needs migrating. The host needs working IPv6 (curl -6 https://ipv6.google.com should answer), and so do the containers: Docker's default network has no IPv6, but on Docker Engine 27 or later a Compose network gets it without touching the daemon config. Windmill's docker-compose.yml uses the default network, so add

  networks:
    default:
      enable_ipv6: true

  and run docker compose up -d again (or down and then up -d). I checked this on Docker 29.8 with "ipv6": false in daemon.json: a container on a network created with IPv6 got a ULA address and reached an IPv6-only host, while the same request from the default bridge failed.

• Supabase's IPv4 add-on is only available on paid plans, so it is not an option on the free tier.

[bmschwa]

Thank you very much for your help @jmrplens.

I added a new supabase project and used the new connection string to make a new postgresql resource, along with a new 'main' data table associated with the resource. I select that as the datasource when installing the app in a new workspace (importing the app into the same workspace looks like is remembering the previous data connection.)

I think that works... but I'm stuck now at "--- BUN INSTALL ---" for type script scripts; python scripts work (but this demo app uses typescript.. so I'm gonna try to figure that out...

[jmrplens]

Good to hear the data table part works now.

On a clean 1.817.0 install that step takes a couple of seconds, and it always prints something after --- BUN INSTALL ---, even when it fails. I ran the three cases on a test instance:

• no imports: empty dependencies, skipping install, straight away;
• an npm import (import dayjs from "dayjs"): bun's install output (Resolving dependencies, bun install v1.4.0, the package list) and the result, in about 2 s;
• a worker with no internet access: error: DNSResolveFailed downloading package manifest ..., and the job fails within seconds.

So if nothing appears after that line for minutes, the worker is stuck rather than failing, and its log should say why. Two things would narrow it down:

1. While a job hangs, run docker compose logs windmill_worker --since 10m and look for errors around that job id.
2. Run two small TypeScript scripts from the script editor on the same instance, one with no imports and one with import dayjs from "dayjs". If the first runs and the second hangs, the problem is between the worker and the npm registry; if both hang, it is the worker itself.

One thing worth checking in that log, since your instance database goes through Supabase's session pooler: in session mode each client keeps its database connection for as long as it holds it, the pool size comes preset by the project's compute size, and Supabase's pooler FAQ notes that "Session mode can queue clients for up to a minute". Every Windmill server and worker opens its own pool of connections, so look for connection or pool timeout errors too.