supabase start fails since v2.112.0: realtime container exits with 'sudo: account validation failure' for the nobody account

[talent-academy-root]

Describe the bug

Starting with CLI v2.112.0, supabase start fails deterministically in our containerised CI runners while initialising the schema. The realtime container exits because sudo cannot switch to the nobody account:

Starting database...
Initialising schema...
+ export ERL_CRASH_DUMP=/tmp/erl_crash.dump
+ echo 'Running migrations'
+ sudo -E -u nobody /app/bin/migrate
sudo: account validation failure, is your account locked?
sudo: a password is required
Stopping containers...
error running container: exit 1

Without --debug the only output is error running container: exit 1, which is why this took a while to pin down — it is indistinguishable from unrelated container failures.

To Reproduce

In a Linux container with Docker available and a project with local migrations:

supabase stop --no-backup
supabase start        # fails at "Initialising schema"

Bisection

We bisected across stable releases on a single machine, 3 supabase start attempts per version, same project, same host, same Docker:

CLI version	supabase start
2.116.0	0/3
2.115.0	0/3
2.114.0	0/3
2.113.0	0/3
2.112.0	0/3
2.111.0	3/3 OK
2.109.1	6/6 OK

The regression is introduced in 2.112.0 and is still present in 2.116.0. All five failing versions produce the identical sudo: account validation failure message, so this looks like a change in the bundled realtime image rather than in the CLI binary itself.

Expected behavior

supabase start completes, or at minimum surfaces the underlying container error without requiring --debug.

System information

• OS: Ubuntu (Linux kernel 7.0.0-30-generic), x86_64
• Docker: 29.1.3 (client and server), storage driver overlayfs, cgroup driver systemd v2
• Supabase CLI: installed from the official .deb release artifacts
• Postgres image pulled by 2.116.0: public.ecr.aws/supabase/postgres:17.6.1.165
• Runs as a non-root user inside an unprivileged system container

Additional context

We have pinned to 2.111.0 as a workaround. Happy to provide more of the --debug output or test a patched image if that helps.

[mandar1045]

Same issue on 2.116.0, upgraded from 2.110.x. Traced it back — getent passwd nobody inside the realtime container shows the account locked on the newer image, wasn't on 2.111.0's. So it's the base image realtime's Dockerfile pulls from, not the CLI.

Root cause is really that sudo is being used to switch to the nobody user in the entrypoint, and sudo checks the account against PAM/shadow before it lets that happen. If the account is locked, sudo just refuses, password or not. gosu does not have this problem because it switches the user directly with setuid, it does not check account status at all. This is actually the main reason people use gosu instead of sudo in containers.

[mandar1045]

Ended up going with runuser instead of gosu for the fix — same idea (skip PAM account validation entirely), but runuser is already in the base image via util-linux, so no new package needed.