DEV Community: nils44344

Gemini 2.5 Flash "no longer available to new users" (404)

nils44344 — Thu, 22 Oct 2026 14:00:00 +0000

The error:

{
  "error": {
    "code": 404,
    "message": "This model models/gemini-2.5-flash is no longer available to new users. Please update your code to use models/gemini-3.8-flash for the latest features and improvements. We recommend you to use the Interactions API (https://ai.google.dev/gemini-api/docs/get-started).",
    "status": "NOT_FOUND"
  }
}

Tested on: @google/genai: 2.27.0 · API key: new, free tier (AI Studio) · Node / OS: 24.14.0 / Windows 11 Pro · Date: October 7, 2026

This isn't your code, and it isn't your key's permissions. Google has retired the 2.x models for keys and projects that didn't use them before. That's why the same code keeps working on a colleague's old key and fails on yours, or works on your laptop and fails in a new deployment with a fresh key.

I called every older model name with a brand-new key. There are three different messages, depending on how old the model is:

Model	Message
`gemini-2.5-flash`, `gemini-2.5-pro`, `gemini-2.5-flash-lite`	`404` "no longer available to new users"
`gemini-2.0-flash`, `gemini-2.0-flash-lite`	`404` "no longer available" (gone for everyone)
`gemini-1.5-flash`, `gemini-1.5-pro`	`404` "is not found for API version v1beta, or is not supported for generateContent"

Each 404 for a 2.x model names its own replacement:

You asked for	The error suggested
`gemini-2.5-flash`	`gemini-3.8-flash`
`gemini-2.5-pro`	`gemini-3.1-pro-preview`
`gemini-2.5-flash-lite`	`gemini-3.5-flash-lite`
`gemini-2.0-flash`	`gemini-3.8-flash`
`gemini-2.0-flash-lite`	`gemini-3.5-flash-lite`

The model list doesn't warn you

If you check ai.models.list() first, you'll still find gemini-2.5-flash, gemini-2.5-pro and gemini-2.5-flash-lite in it, listed as supporting generateContent. Then the call 404s. So "it's in the list" doesn't mean your key can use it: only a real call tells you.

The fix

Change the model name. These worked with the new free key:

const res = await ai.models.generateContent({
  model: 'gemini-3.5-flash', // or 'gemini-3.5-flash-lite'
  contents: 'hi',
});

✅ gemini-3.5-flash and gemini-3.5-flash-lite both answered normally with the same key that got the 404.

To stop this happening at the next retirement, you can use the moving alias instead of a version number. gemini-flash-lite-latest answered, and the response's modelVersion showed it was serving gemini-3.5-flash-lite:

const res = await ai.models.generateContent({ model: 'gemini-flash-lite-latest', contents: 'hi' });
console.log(res.modelVersion); // gemini-3.5-flash-lite

The cost of an alias: the model behind it changes without notice, so output and pricing can shift under you. Log modelVersion so you can see when it does.

Don't jump straight to the suggested model

The 404 for gemini-2.5-flash says to use gemini-3.8-flash. Every time I tried it that evening, it returned 503 "This model is currently experiencing high demand" or timed out, and gemini-flash-latest did the same. Meanwhile, older models kept answering. The newest model is the busiest one. Test the replacement before you ship it.

And for the Pro suggestion (gemini-3.1-pro-preview): on the free tier its quota is 0, so switching to it turns your 404 into a 429. That one is covered in Gemini API 429 RESOURCE_EXHAUSTED: why your limit is 0.

What didn't work

❌ Checking models.list() before calling. The retired 2.5 models are still listed for a key that can't use them.

❌ Using the exact model the error recommends, as is. gemini-3.8-flash returned 503 or timed out every time I called it, and the recommended Pro model has no free-tier quota at all.

💡 Same idea, different provider Groq retired its Llama models the same way, with a model_not_found error: Groq API error 413, 429 and model_not_found.

How this was tested

A free Google AI Studio key on October 7, 2026 (a new one: it got the "to new users" 404), with @google/genai 2.27.0 on Node 24.14.0 (Windows 11). Every model was called once with a one-word prompt and maxOutputTokens: 1. The model list came from ai.models.list() with the same key. I didn't have an older key to confirm that the 2.5 models still work for existing users. That part is what the error message itself says ("to new users"), not something I saw. Google retires models on its own schedule, so check the date above.

The code for every case above is public, so you can run it yourself: gemini-429 in nk-repro.

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.

Prisma P1001: Can't reach database server at localhost:5432

nils44344 — Mon, 19 Oct 2026 14:00:00 +0000

The error:

Error: P1001: Can't reach database server at `localhost:5432`

Please make sure your database server is running at `localhost:5432`.

Tested on: prisma: 6.19.3 and 7.10.0 · Postgres: 17 (Docker), Supabase CLI 2.120.0 local · Docker: Desktop 4.94.0, node:24-alpine · Node / OS: 24.14.0 / Windows 11 Pro

P1001 means Prisma opened no connection at all. It never got as far as your password or your database name. The trouble is that it prints exactly the same sentence whatever the reason. I triggered it five different ways, and the message only ever changed in the host and port:

What was wrong	What Prisma 6 said
Nothing listening on that port (database stopped, or wrong port)	P1001: Can't reach database server at `localhost:5432`
Host name doesn't exist on this machine (`postgres`, a Compose service)	P1001: Can't reach database server at `postgres:5432`
Host exists but never answers (firewall, wrong IP)	P1001: Can't reach database server at `10.255.255.1:5432`
App inside a container using `localhost`	P1001: Can't reach database server at `localhost:5432`
Something is listening, but it isn't Postgres (Supabase's API port)	P1001: Can't reach database server at `127.0.0.1:54321`

Step 1: find out which one you have

Ask the network directly, with the same host and port as in your error. Node is already installed, so this works on any OS:

node -e "const s=require('net').connect(5432,'localhost');s.setTimeout(5000);s.on('connect',()=>{console.log('open: something is listening');s.destroy()}).on('timeout',()=>{console.log('timeout: no answer at all');s.destroy()}).on('error',e=>console.log(e.code))"

Put your host and port into connect(5432,'localhost'). What it printed for each case:

Output	Meaning	Go to
`ECONNREFUSED`	The machine is there, nothing is listening on that port	Nothing listening
`ENOTFOUND`	The host name doesn't resolve from where you ran it	Docker
`timeout: no answer at all`	Packets go nowhere: firewall, wrong IP, or IPv6	Timeouts
`open: something is listening`	A server is there. Check it's Postgres on that port	Wrong service

Run it from the same place your app runs: inside the container if the app is in a container. Otherwise you're testing a different network.

Nothing is listening on that port

With my Postgres container stopped, and separately with the right server but the default port 5432 (mine was mapped to 55432), Prisma gave the P1001 above in both cases. The quick check said ECONNREFUSED.

Start the database, and make the port in DATABASE_URL match the one it really listens on. For Docker, the left side of the port mapping is the one your machine uses:

$ docker ps --format "{{.Names}} {{.Ports}}"
nk-pg 0.0.0.0:55432->5432/tcp

DATABASE_URL="postgresql://postgres:password@localhost:55432/postgres"

✅ With the container running and port 55432 in the URL, prisma db push reached the database and synced the schema.

Docker: localhost and service names

Most P1001 reports involve Docker, because "localhost" means a different machine depending on where the code runs. I ran Prisma inside a node:24-alpine container on the same Docker network as Postgres (service name postgres, container port 5432, mapped to 55432 on the host):

From inside the app container	Result
`localhost:5432`	P1001: the container's own localhost has no Postgres
`localhost:55432` (the port mapped on the host)	P1001
`postgres:55432` (service name + host port)	P1001: wrong side of the mapping
`postgres:5432` (service name + container port)	✅ in sync
`host.docker.internal:55432`	✅ in sync (Docker Desktop)

And the reverse mistake: running npx prisma migrate on your machine with the URL from your Compose file. postgres only exists inside Docker's network, so from Windows I got P1001: Can't reach database server at `postgres:5432` (the quick check said ENOTFOUND).

Use the address for where the code runs:

# app running in a container on the same Compose network
DATABASE_URL="postgresql://postgres:password@postgres:5432/postgres"

# prisma CLI running on your machine
DATABASE_URL="postgresql://postgres:password@localhost:55432/postgres"

Service name with the container port inside Docker; localhost with the host port outside it. If you run migrations from both places, they need different URLs. Pass the right one per command, or keep two .env files.

No answer at all: firewalls, IPs and Supabase

When nothing answers at all, the quick check prints timeout. Prisma 6's CLI failed about as fast as it did for a closed port, but a Prisma 7 app waited about 30 seconds first (see the Prisma 7 table below). Usually it's a firewall or security group not allowing your IP, a VPN, or simply the wrong IP.

For hosted Supabase there's a common version of this that I couldn't reproduce here (it needs a hosted project). Per Supabase's connection docs, the direct host db.<project>.supabase.co is IPv6 unless you pay for the IPv4 add-on. On an IPv4-only network (many home ISPs, some CI runners and hosts) it can't be reached at all.

For Supabase from an IPv4-only network, use the Session pooler connection string from the dashboard's Connect panel (aws-…pooler.supabase.com:5432) instead of the direct db.<project>.supabase.co one. If you use the transaction pooler (port 6543) with Prisma, Supabase says to add ?pgbouncer=true. Neither of these was tested here: no hosted project.

Once Prisma connects, Supabase's API can still refuse your writes with a different code. That one is Supabase error 42501.

Something is listening, but it isn't Postgres

The local Supabase stack runs the database on 54322 and its HTTP API on 54321. Pointing Prisma at 54321 didn't give a protocol error. It gave the same P1001, even though the port was open and answering:

Error: P1001: Can't reach database server at `127.0.0.1:54321`

Port 54322 worked. If the quick check says open but Prisma says P1001, compare your port with what's actually serving Postgres.

Prisma 7 doesn't always say P1001

In Prisma 7, the CLI (prisma migrate dev) still prints P1001. But in your app, which talks to the database through a driver adapter such as @prisma/adapter-pg, the same problems produced three different errors:

Problem	Prisma 7 app error
Database stopped	`PrismaClientKnownRequestError`, `code: 'ECONNREFUSED'`, and a message with no reason in it, just the invocation
Host name doesn't resolve	`code: 'P1001'`, "Can't reach database server at postgres", `meta.driverAdapterError.cause.kind: 'DatabaseNotReachable'`
Unreachable IP	`code: 'P1008'`, "Operation has timed out", `kind: 'SocketTimeout'`, after about 30 seconds

So if you only grep logs for P1001 on Prisma 7, you'll miss the stopped database entirely. Prisma 6's client, for comparison, threw PrismaClientInitializationError with the same "Can't reach database server" text as the CLI.

What didn't work

❌ Changing the password or the database name. P1001 happens before Prisma ever sends them. In all five cases here, the credentials were never checked.

❌ Using the host-side port inside Docker. postgres:55432 and localhost:55432 both failed inside the container. The host port only exists on the host.

❌ Trusting "something is listening". Supabase's API port was open and still gave P1001. An open port isn't necessarily Postgres.

How this was tested

Postgres 17 in Docker Desktop 4.94.0 on Windows 11, mapped to port 55432, with Prisma 6.19.3 (prisma db push and a client query) and Prisma 7.10.0 (prisma migrate dev, plus queries through @prisma/adapter-pg). Each failure was produced on purpose: container stopped, wrong port, Compose host name used from Windows, a non-routable IP (10.255.255.1), and the API port of a local Supabase stack (CLI 2.120.0). The container cases ran in node:24-alpine on a user-defined Docker network with Postgres aliased as postgres. Hosted Supabase (IPv6, poolers) wasn't tested: those notes come from Supabase's documentation, linked above.

The code for every case above is public, so you can run it yourself: prisma6-noinit and prisma-init in nk-repro.

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.

Gemini API 429 RESOURCE_EXHAUSTED: why your limit is 0

nils44344 — Fri, 16 Oct 2026 14:00:00 +0000

The error:

{
  "error": {
    "code": 429,
    "message": "You exceeded your current quota, please check your plan and billing details. ...
* Quota exceeded for metric: generativelanguage.googleapis.com/generate_content_free_tier_requests, limit: 0, model: gemini-3.1-pro
Please retry in 10h17m5.723541104s.",
    "status": "RESOURCE_EXHAUSTED"
  }
}

Tested on: @google/genai: 2.27.0 · API tier: Free (AI Studio key) · Node / OS: 24.14.0 / Windows 11 Pro · Date: October 7, 2026

Every Gemini quota error looks the same at first: HTTP 429, "status": "RESOURCE_EXHAUSTED", "You exceeded your current quota". The part that matters is one line further down, in the * Quota exceeded for metric lines: the limit number and the model. With a free AI Studio key I hit three different ones on purpose, and each one needs a different fix:

The message says	What it means	Retry delay it gave me
`limit: 0, model: gemini-3.1-pro`	Your tier has no quota for this model	`10h17m` (waiting doesn't help)
`limit: 5, model: gemini-3.5-flash`	Requests per minute used up	`46s`
`limit: 20, model: gemini-3.5-flash`	Requests per day used up	`9h54m`, until 00:00 UTC

The details array names the quota exactly. The per-minute one was GenerateRequestsPerMinutePerProjectPerModel-FreeTier, the daily one GenerateRequestsPerDayPerProjectPerModel-FreeTier.

`limit: 0`: the model isn't in your tier

This was the first call I made with the key. It wasn't a burst: a single request to gemini-3.1-pro-preview came back 429 straight away. Same for gemini-pro-latest. On the free tier these models have a quota of zero. The error still says "Please retry in 10h17m", but that only marks when the daily counters reset. Retrying at that time gets the same limit: 0.

Use a model that your tier has quota for. With this free key, gemini-3.5-flash, gemini-3.5-flash-lite and gemini-flash-latest answered normally:

const res = await ai.models.generateContent({
  model: 'gemini-3.5-flash',
  contents: 'hi',
});

If you need the Pro model specifically, that means a paid tier (billing turned on for the Google Cloud project behind the key). I didn't test that: it costs money, and it's the only way past a limit: 0.

Per-minute limit: wait the time it gives you

Sending one tiny request after another to gemini-3.5-flash, calls 1 to 7 succeeded, and call 8 failed 8.4 seconds in:

* Quota exceeded for metric: generativelanguage.googleapis.com/generate_content_free_tier_requests, limit: 5, model: gemini-3.5-flash
Please retry in 46.130728812s.

The limit says 5, but seven got through first, so don't use the number to pace yourself exactly. The @google/genai SDK (2.27.0) threw this straight to my code: it didn't retry on its own.

Wait the retryDelay from the error's RetryInfo detail, then retry. But cap the wait, because a daily limit sends a delay of hours:

import { GoogleGenAI, ApiError } from '@google/genai';
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

async function generateWithRetry(params, maxWaits = 4) {
  for (let attempt = 0; ; attempt++) {
    try {
      return await ai.models.generateContent(params);
    } catch (err) {
      if (!(err instanceof ApiError) || attempt >= maxWaits) throw err;
      if (err.status === 503) { // "high demand": back off and try again
        await new Promise((r) => setTimeout(r, 2000 * 2 ** attempt));
        continue;
      }
      if (err.status !== 429) throw err;
      const body = JSON.parse(err.message).error;
      if (/limit: 0\b/.test(body.message)) throw err; // no quota for this model at all
      const delay = body.details?.find((d) => d['@type']?.endsWith('RetryInfo'))?.retryDelay ?? '10s';
      const ms = Math.ceil(parseFloat(delay) * 1000) + 500;
      if (ms > 120_000) throw err; // a daily quota: the delay runs to midnight UTC
      await new Promise((r) => setTimeout(r, ms));
    }
  }
}

✅ After the per-minute 429, waiting 50 seconds and calling again succeeded. With the helper, a limit: 0 model and a used-up daily quota both failed at once instead of hanging, which is what you want: neither one recovers by waiting a minute.

⚠️ The SDK's retryOptions won't cover this @google/genai has httpOptions.retryOptions (attempts, backoff starting at 1 second, up to 60). Exponential backoff guesses at the wait. The error already tells you the exact delay, and for a daily limit no amount of backoff is long enough.

Daily limit: it resets at midnight UTC, not Pacific time

My test calls used up gemini-3.5-flash's free daily quota (limit: 20). The retry delay pointed at 2026-10-08 00:00:13 UTC. That's 8 PM in New York and 5 PM in San Francisco, not midnight Pacific as a lot of older answers say.

Switch to a different model until the reset. Each model has its own counters: right after gemini-3.5-flash hit its daily limit, nine calls in a row to gemini-3.5-flash-lite all succeeded.

💡 The quota IDs end in PerProjectPerModel: the counters belong to the Google Cloud project behind the key, and to one model. From that wording, a second key in the same project would share them. I didn't create one to check.

Not a 429: "This model is currently experiencing high demand"

While I was testing, gemini-3.8-flash (the newest Flash) returned this on every call, and later gemini-3.5-flash did too, for a few calls:

{
  "error": {
    "code": 503,
    "message": "This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.",
    "status": "UNAVAILABLE"
  }
}

This is Google being overloaded, not your quota. There's no retry delay in it, and other models kept working at the same moment. Calls that did go through during that period were slow, too: one took 56 seconds.

Back off and retry, or use another model for a while. The helper above waits 2, 4, then 8 seconds. In my run the 503s stopped after those three waits (the next answer was the daily-limit 429, because by then my test calls had used up the day's quota).

What didn't work

❌ Waiting out the "retry in 10h" on a limit: 0 model. That delay only points to the daily reset. The quota for that model on the free tier is zero, so it's zero again after the reset.

❌ Trusting the limit number to pace requests. With limit: 5 per minute, seven requests got through before the 429. Pace from the 429 and its delay, not from the number.

❌ Retrying a daily limit with backoff. My first helper honoured the delay with no cap and went to sleep for 36,030 seconds. If a delay is longer than a couple of minutes, it's a daily quota: stop and switch model.

💡 Gemini says the model is gone? With a new key, gemini-2.5-flash and gemini-2.5-pro didn't return a 429 at all. They returned 404 "no longer available to new users". That's a different fix (the model name), not your quota.

How this was tested

A free Google AI Studio API key on October 7, 2026, with @google/genai 2.27.0 on Node 24.14.0 (Windows 11). Every request was one word with maxOutputTokens: 1, sent one after another, never in parallel. Limits were reached on purpose: a Pro model for limit: 0, a fast loop for the per-minute limit, and the day's test calls for the daily one. The limits shown are the free tier's on that day. Google changes them, so read the numbers in your own error message. I didn't test paid tiers, Vertex AI, or the Gemini CLI, whose 429s come from a different quota.

The code for every case above is public, so you can run it yourself: gemini-429 in nk-repro.

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.

Supabase error 42501: new row violates row-level security policy

nils44344 — Tue, 13 Oct 2026 14:00:00 +0000

The error:

{
  code: '42501',
  details: null,
  hint: null,
  message: 'new row violates row-level security policy for table "profiles"'
}

Tested on: supabase-js: 2.117.2 · Supabase CLI: 2.120.0 (local stack) · Postgres: 17.11 · PostgREST: 16.4 · Node / OS: 24.14.0 / Windows 11 Pro

42501 is Postgres's code for "insufficient privilege". Supabase returns it in two very different situations, and the message tells you which one you're in:

Message	What blocked the request	Status
`new row violates row-level security policy for table "x"`	A row-level security (RLS) policy	`401` signed out, `403` signed in
`new row violates row-level security policy (USING expression) for table "x"`	The same, on an upsert that hit an existing row	`403`
`new row violates row-level security policy` (no table name)	A Storage upload	`statusCode: "403"`
`permission denied for table x`	A missing table GRANT (not a policy)	`401` / `403`

The first three are about policies. The last one is about grants, and it's the one that will suddenly show up on existing projects after October 30, 2026 (see the last section). Adding a policy does nothing for it, and I tested that.

I reproduced every row of that table on a local Supabase stack, with supabase-js calling the real API. Each section below starts with what triggered it and ends with the change that made the same call succeed.

Which policy is missing

Supabase's RLS denies by default, per operation. A table with RLS on and only a SELECT policy can be read but not written. Inserting with the publishable (anon) key returned:

status: 401 Unauthorized
code: '42501'
message: 'new row violates row-level security policy for table "notes_selectonly"'

The same table with no policies at all behaved differently for reads: select() came back 200 with data: []. No error, just an empty list. So "reads work, writes fail" usually means you wrote a read policy and nothing else.

Add a policy for the operation that failed. For a table anyone can write to:

create policy "anyone can insert" on public.notes_selectonly
  for insert to anon, authenticated
  with check (true);

For rows that belong to a user (the usual profiles case), check the owner:

create policy "insert own profile" on public.profiles
  for insert to authenticated
  with check ((select auth.uid()) = id);

✅ With the policy in place, the same insert returned 201 Created.

`.insert().select()` needs a SELECT policy too

This one catches people who did write an INSERT policy. With only an INSERT policy on the table:

insert({ body: 'x' }) returned 201 Created.
insert({ body: 'x' }).select() returned 401 and the same 42501 message.

Asking for the row back means Postgres has to be allowed to read the new row, and without a SELECT policy it isn't. The whole insert is rolled back: I counted the rows afterwards, and the failed call left nothing behind.

Add a SELECT policy that covers the new row:

create policy "anyone can read" on public.notes_insertonly
  for select to anon, authenticated
  using (true);

✅ insert().select() then returned 201 with the new row in data.

You're not signed in (yet)

A policy written to authenticated doesn't apply to a request made with the anon key and no session. In my test the profiles insert failed with 401 when signed out, and with 403 when signed in but inserting someone else's id. Same code, same message, different status. If you see 401, check that the client really has a session at the moment of the insert. One way to end up without one, which I didn't reproduce here: inserting the profile right after signUp() on a project with email confirmation on, where sign-up doesn't return a session yet.

`user_id` isn't sent, so the check fails

With a policy like with check ((select auth.uid()) = user_id), an insert that leaves user_id out writes null, and null = <your id> is not true. Signed in, insert({ task: 't' }) failed with 403 and 42501. Sending the column worked, but the cleaner fix is to stop relying on the client for it.

Make the database fill it in:

alter table public.todos alter column user_id set default auth.uid();

✅ The same insert({ task: 't' }), with no user_id, then returned 201.

Upsert: the "(USING expression)" version

upsert() is an insert that can turn into an update. With INSERT and SELECT policies but no UPDATE policy:

The first upsert() (new row) returned 201.
The second upsert() on the same id returned 403 with:

new row violates row-level security policy (USING expression) for table "profiles"

Related trap: a plain .update() with no UPDATE policy did not error at all. It returned 200, changed nothing, and gave back an empty list.

Add an UPDATE policy. It needs using (which rows you may touch) and with check (what they may become):

create policy "update own profile" on public.profiles
  for update to authenticated
  using ((select auth.uid()) = id)
  with check ((select auth.uid()) = id);

✅ The repeat upsert() then returned 200, and .update() returned the changed row.

Storage uploads

Storage keeps its files as rows in storage.objects, so uploads go through RLS too. A bucket with no policy on that table refused an upload with:

StorageApiError: new row violates row-level security policy
status: 400, statusCode: '403'

There's no table name in this one, and the HTTP status (400) doesn't match the statusCode field (403). Once uploads worked, uploading to an existing name with upsert: true failed again with code: 'AccessDenied' and the same message. Overwriting replaces an existing row, and an INSERT policy only covers new ones.

Policies on storage.objects, scoped to the bucket. Insert for new uploads:

create policy "upload avatars" on storage.objects
  for insert to anon, authenticated
  with check (bucket_id = 'avatars');

And for upsert: true, SELECT and UPDATE as well:

create policy "read avatars" on storage.objects
  for select to anon, authenticated
  using (bucket_id = 'avatars');

create policy "overwrite avatars" on storage.objects
  for update to anon, authenticated
  using (bucket_id = 'avatars');

✅ With the insert policy, new uploads returned a path and id. With all three, upsert: true overwrote the file. I added SELECT and UPDATE together, so I can't say whether UPDATE alone is enough.

💡 Use authenticated, not anon, in a real app I used anon so the test didn't need a login. In production, scope uploads to authenticated, and usually to the user's own folder.

"permission denied for table": the October 30 change

Supabase's API used to give anon, authenticated and service_role full access to every new table in public automatically, leaving RLS to do the filtering. That automatic grant was switched off for new projects on May 30, 2026. Per Supabase's changelog, it applies to all existing projects on October 30, 2026. Tables that already exist keep their grants; tables you create after that don't get any.

The local CLI has the same switch (auto_expose_new_tables in supabase/config.toml). I turned it off and created an orders table with RLS enabled and working policies. Every call failed anyway:

status: 401 Unauthorized
code: '42501'
message: 'permission denied for table orders'
hint: 'Grant the required privileges to the current role with: …'

Two things surprised me:

Policies don't matter here. Postgres checks table privileges before it ever looks at RLS. With the grants added and the INSERT policy dropped, the error switched to the RLS message. So the order is: grant first, then policy.
service_role fails too. The service key bypasses RLS, but not grants. A server-side select() with the service key returned 403, with a hint naming the privilege it lacked.

The hint is worth reading: it names the exact privileges that call needed. For the anon read it was GRANT SELECT ON public.orders TO anon;, and insert().select() as a signed-in user asked for GRANT SELECT, INSERT ON public.orders TO authenticated;.

Grant the API roles access to the new table, then keep RLS on:

grant select on public.orders to anon;
grant select, insert, update, delete on public.orders to authenticated;
grant select, insert, update, delete on public.orders to service_role;
alter table public.orders enable row level security;

✅ All four calls (anon read, anon insert, service key read, signed-in insert) then succeeded. Only grant anon what logged-out visitors should really do. I granted it INSERT as well, only so I could run the anon test.

If you create tables in migrations, put the grants in the same migration as the create table. Otherwise the table works on your old project and fails on the next one.

What didn't work

❌ Disabling RLS. It "fixed" every policy error: anon inserts returned 201. It also let the anon key read every row in the table, including rows other users had inserted. The anon key ships in your frontend, so anyone could do the same. It also does nothing for "permission denied for table", which is about grants.

❌ Adding a policy for "permission denied for table". The orders table had SELECT and INSERT policies the whole time. Until the GRANT existed, they were never reached.

❌ Switching the client to the service_role key. It bypassed RLS (the no-policy insert returned 201), but it was still blocked by a missing grant. And a service key in browser code gives everyone full access to your database.

How this was tested

A local Supabase stack (CLI 2.120.0: Postgres 17.11, PostgREST 16.4, GoTrue 2.197.0, Storage 1.79.36) in Docker Desktop on Windows 11, called from Node 24.14.0 with @supabase/supabase-js 2.117.2. Each case was a table built in a migration with exactly one thing missing, called with the publishable (anon) key, as a freshly signed-up user, and with the service key. Every fix was applied on its own, and the same call rerun. The "permission denied" cases used auto_expose_new_tables = false locally, which is the setting Supabase applies to hosted projects. I didn't run them against a hosted project, and I didn't test the GraphQL API, which the same change also affects.

The code for every case above is public, so you can run it yourself: supabase-42501 in nk-repro.

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.

Fix: @prisma/client did not initialize yet (Prisma 6 and 7)

nils44344 — Sat, 10 Oct 2026 14:00:00 +0000

The error:

D:\project\node_modules\.prisma\client\default.js:43
    throw new Error('@prisma/client did not initialize yet. Please run "prisma generate" and try to import it again.');
    ^

Error: @prisma/client did not initialize yet. Please run "prisma generate" and try to import it again.
    at new PrismaClient (D:\project\node_modules\.prisma\client\default.js:43:11)

Tested on: prisma / @prisma/client: 6.19.3 and 7.10.0 · npm: 11.9.0, 11.19.0, 12.2.0 · Node: 24.14.0 (Windows), 24.21.0 (Ubuntu, WSL) · OS: Windows 11 Pro + Ubuntu 24.04

@prisma/client doesn't contain your client. It contains a placeholder that throws this error until prisma generate writes the real one, built from your schema.prisma. So the message is literally true: generate hasn't run, or didn't finish, in the copy of node_modules your app is loading.

The confusing part is that npm install is supposed to run it for you. I reproduced four situations where it doesn't, plus what changed in Prisma 7, where you don't get this message at all:

Situation	Message you get
Install didn't generate (Windows, or schema added after install)	`@prisma/client did not initialize yet`
`npm ci --ignore-scripts`	`Cannot find module '.prisma/client/default'`
npm 12 blocked Prisma's install script	`Cannot find module '.prisma/client/default'`
Prisma 7, generate never ran	`Named export 'PrismaClient' not found` (ESM), `does not provide an export named 'PrismaClient'` (TypeScript), or `Cannot find module '.prisma/client/default'` (CommonJS)

The fix

Run it once to unblock yourself:

npx prisma generate

✔ Generated Prisma Client (v6.19.3) to .\node_modules\@prisma\client in 215ms

Then stop depending on the install doing it. Add it to your own scripts in package.json:

"scripts": {
  "postinstall": "prisma generate"
}

✅ With that script, a clean npm ci printed ✔ Generated Prisma Client and the app started, on Windows (npm 11.9.0) and on Linux with npm 12.2.0, which blocks Prisma's own install script.

A project's own postinstall is a different thing from a dependency's install script. That's why the line above keeps working on npm 12, where Prisma's script is blocked.

On Windows, the install didn't generate for me

Same package.json, same lockfile, same prisma/schema.prisma, Prisma 6.19.3:

On Ubuntu (WSL, npm 11.19.0), npm ci printed ✔ Generated Prisma Client (v6.19.3) during the install, and the app ran.
On Windows 11 (npm 11.9.0), npm ci ran @prisma/client's postinstall without any error, generated nothing, and the app threw did not initialize yet. It happened from PowerShell and from Git Bash, and running npm rebuild @prisma/client changed nothing.

The script is written to fail silently. It looks for the Prisma CLI by resolving the prisma package, and Prisma 6's package points its entry at ./build/types.js, a file that isn't in the published package (I checked 6.6.0 through 6.19.3). So that lookup always fails, and the script falls back to running prisma -v on the PATH. That evidently worked on Linux and not on this Windows machine. I didn't trace that last step further, but the fix above doesn't depend on it.

The same thing happens on any OS if you add schema.prisma after installing, because the install already ran with no schema to generate from.

`npm ci --ignore-scripts` (and CI templates that use it)

Skipping install scripts skips Prisma's too, so not even the placeholder gets written:

Error: Cannot find module '.prisma/client/default'

Same cause, different message. The project-level postinstall doesn't help here either, because --ignore-scripts skips it too.

When you install with --ignore-scripts, generate as its own build step:

npm ci --ignore-scripts
npx prisma generate

npm 12 blocks Prisma's install script

npm 12 doesn't run dependencies' install scripts unless you approve them (more on that in npm 12 breaking changes, tested). On Ubuntu, a clean npm ci with npm 12.2.0 warned:

npm warn install-scripts 3 packages had install scripts blocked because they are not covered by allowScripts:
npm warn install-scripts   @prisma/client@6.19.3 (postinstall: node scripts/postinstall.js)
npm warn install-scripts   @prisma/engines@6.19.3 (postinstall: node scripts/postinstall.js)

The app then failed with Cannot find module '.prisma/client/default'. The postinstall in the fix solves it. If you'd rather let Prisma's own script run, approve it by name:

"allowScripts": {
  "@prisma/client": true,
  "@prisma/engines": true,
  "prisma": true
}

✅ With these three approved, npm 12 printed no warning and the app started.

⚠️ Don't add it with npm pkg set I first tried npm pkg set "allowScripts.@prisma/client@6.19.3"=true. npm split the key on its dots, and npm 12 then ignored it with semver ranges (^, ~, >=, <) are not allowed. Edit package.json by hand.

`npm i prisma` gave you Prisma 8

If npx prisma generate itself fails with No command registered for `generate`, the CLI you installed is the Prisma 8 release candidate, which npm currently serves as prisma@latest. Generate never runs, so you end up here. That one has its own fix: prisma generate not working: "No command registered".

Prisma 7 throws different errors

Prisma 7.10.0 doesn't ship the placeholder, so the same mistake (no generate) surfaces as a module error instead. Which one depends on how you import:

ESM (.mjs):   SyntaxError: Named export 'PrismaClient' not found. The requested module '@prisma/client' is a CommonJS module...
TypeScript:   SyntaxError: The requested module '@prisma/client' does not provide an export named 'PrismaClient'
CommonJS:     Error: Cannot find module '.prisma/client/default'

The ESM message even suggests import pkg from '@prisma/client'. That changes nothing here: the module still has nothing in it until generate runs. The fix is the same prisma generate.

Once that's done, Prisma 7's next error is usually this one:

PrismaClientInitializationError: PrismaClient was instantiated without any options. A driver adapter is required to connect to your database.

Prisma 7 needs a driver adapter. For Postgres:

import { PrismaPg } from '@prisma/adapter-pg';
const prisma = new PrismaClient({ adapter: new PrismaPg({ connectionString: process.env.DATABASE_URL! }) });

✅ With @prisma/adapter-pg 7.10.0 this ran an upsert against Postgres 17.

What didn't work

❌ Reinstalling @prisma/client. On Windows, deleting node_modules and running npm ci again brought the same error back every time. The install never generated there.

❌ npm rebuild @prisma/client. It re-ran Prisma's install script, which again finished silently without generating.

❌ The default import the ESM error suggests. In Prisma 7 it just moved the failure, because there was still nothing to import.

How this was tested

One small project (a User model, the prisma-client-js generator, a script that does new PrismaClient()) installed from the same lockfile on Windows 11 with npm 11.9.0, in PowerShell and Git Bash, and on Ubuntu 24.04 in WSL with npm 11.19.0 and npm 12.2.0. Prisma 6.19.3 for the main error, then 7.10.0 for the Prisma 7 messages, run as CommonJS, ESM and TypeScript (tsx). Every fix was checked from a clean node_modules. I didn't test Docker, Vercel, pnpm or Yarn. A production install without dev dependencies (npm ci --omit=dev) didn't reproduce the error on Linux, so it isn't listed as a cause.

The code for every case above is public, so you can run it yourself: prisma6-noinit and prisma-noinit in nk-repro.

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.

Next.js 16.3 vulnerabilities: which version is patched?

nils44344 — Fri, 09 Oct 2026 14:00:00 +0000

Verdict: 16.3.0 carries 9 published advisories (3 critical) and 16.3.7 still carries 6, because the September 30 fixes skipped it. The upgrade built cleanly on every version I tried. The traps are in the tools: npm audit fix jumps you a minor version or does nothing at all, and next upgrade crashes on Windows.

Tested on: next: 16.3.0, 16.3.7, 16.3.8, 16.4.0 · npm: 11.9.0 · Node / OS: 24.14.0 / Windows 11 Pro · Advisories: GitHub, as of Oct 8, 2026

Next.js has published a lot of security fixes since July, and the version numbers don't make it obvious which release actually has them. The worst case is 16.3.7: it came out on September 29, the day before a scheduled security release, and it's a bug-fix release only. Next.js's own announcement says so.

So I took one small App Router app (an image, a server action, a next/og route and middleware: the features the advisories touch) and ran npm audit and next build on it at each step.

What npm audit says at each version

next	npm audit for `next`	Build
16.3.0	9 advisories: 3 critical, 1 high, 4 moderate, 1 low	✅ passes
16.3.7	6 advisories: 1 high, 4 moderate, 1 low	✅ passes
16.3.8	not flagged	✅ passes
16.4.0 (`latest`)	not flagged	✅ passes

To stay on the 16.3 line, install the patched release:

npm i next@16.3

That resolved to 16.3.8. If you're ready for the newer minor version, npm i next@latest gives you 16.4.0. Both builds of the test app passed with no new warnings.

The only warning on every version was one that has nothing to do with security: The "middleware" file convention is deprecated. Please use "proxy" instead. It's printed on 16.3.0 too, so it isn't something the upgrade added.

Which release fixed what

From the published advisories for the 16.3 line:

Released	Patched in	Fixed
Aug 25	16.3.3, 15.5.24	Two critical remote code execution bugs: one in the Image Optimization API with AVIF files, one on Windows-hosted servers
Sep 22	16.3.6, 15.5.26	A critical remote code execution bug in `next/og`'s `ImageResponse`
Sep 30	16.3.8, 15.5.27	Seven more: a high SSRF in Image Optimization, five medium (cache poisoning of SSG/ISR pages, `use cache` leaks, a metadata image route disclosure) and one low (the dev server's MCP endpoint)

The September 30 announcement also says two more issues, one critical and one high, are "pending upstream coordination and will be addressed in a later Next.js release". So today's patched release won't be the last one you need. npm audit can only flag what's been published.

I tested the 16.x line only. The 15.x versions above come from the advisories.

npm audit fix doesn't do what you'd expect

The obvious fix behaved differently depending on how next was written in package.json:

package.json had	`npm audit fix` result
`"next": "^16.3.0"`	Installed 16.4.0, a new minor version, not the 16.3 patch release. `package.json` unchanged.
`"next": "16.3.0"` (exact)	Did nothing. Printed `fix available via npm audit fix --force`.
exact, then `npm audit fix --force`	Installed 16.4.0 and rewrote the pin to `^16.4.0`.

The exact pin isn't unusual: create-next-app@16.3.0 writes "next": "16.3.0" exactly. So on a freshly scaffolded project, npm audit fix leaves every advisory in place, and the forced version quietly removes the pin you had. npm update next on a caret range also went to 16.4.0.

next upgrade crashes on Windows

Next.js has its own upgrade command, and on Windows it failed immediately, from PowerShell and from Git Bash:

$ npx next upgrade --revision 16.3.8
Error: spawn npx ENOENT
    at onErrorNT (node:internal/child_process:484:16)
  ...
  spawnargs: [ '--yes', '@next/codemod@canary', 'upgrade', '16.3.8' ]

It's reported upstream (vercel/next.js#97980). The fix (#98075) was still unmerged when I tested, and 16.4.0's next upgrade crashed the same way.

Run the command next upgrade tries to launch, directly:

npx --yes @next/codemod@canary upgrade 16.3.8

✅ On Windows this upgraded 16.3.0 to 16.3.8, kept the exact pin ("next": "16.3.8"), and npm reported found 0 vulnerabilities.

What's new in 16.4.0

16.4.0 came out on October 6. From its release notes: next dev and next build now nudge you when your version has known security issues, next upgrade --ai adds vulnerability coverage, and the Pages Router deprecates React 18. I only built the test app on it (it passed); I didn't test the nudges or the AI upgrade.

What didn't work

❌ Upgrading to 16.3.7. It looks like the newest 16.3 patch from September, but it's the bug-fix release from the day before the security release. npm audit still flagged 6 advisories.

❌ npm audit fix on an exact version. It changed nothing and asked for --force, which then moved to 16.4.0 and dropped the pin.

❌ next upgrade on Windows. spawn npx ENOENT on 16.3.0 and on 16.4.0.

How this was tested

One App Router app (TypeScript, next/image, a server action, a next/og route, a middleware file) on Windows 11 with Node 24.14.0 and npm 11.9.0. For each of next 16.3.0, 16.3.7, 16.3.8 and 16.4.0: npm audit --json (counting the advisories listed under next) and next build (Turbopack). Then npm audit fix, npm audit fix --force, npm update next and a direct install of the 16.3 line, each starting again from 16.3.0, with both caret and exact versions in package.json. Severities and counts are npm's on October 8, 2026, and will change as new advisories are published. I didn't test the vulnerabilities themselves, the Pages Router, custom servers or the 15.x line.

The code for every case above is public, so you can run it yourself: next-security in nk-repro.

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.

prisma generate not working: "No command registered" (Prisma 8)

nils44344 — Wed, 07 Oct 2026 17:17:26 +0000

The error:

{"kind":"result","envelope":{"ok":false,"commandId":"","error":{"code":"CLI.UNKNOWN_COMMAND","severity":"error","summary":"No command registered for `generate`","nextActions":[{"kind":"run-command","label":"List every command","command":"prisma --help"}]}}}

Tested on: prisma (latest tag): 8.0.0-rc.20 · prisma / @prisma/client: 7.10.0 · Postgres: 17 (Docker) · Node / OS: 24.14.0 / Windows 11 Pro

Nothing is wrong with your schema. On npm, prisma@latest now points to 8.0.0-rc.20, a release candidate of Prisma ORM 8. It's a new command-line tool that doesn't read schema.prisma and has no generate, migrate dev or db push. Meanwhile @prisma/client@latest is still 7.10.0. So a fresh npm i prisma @prisma/client today gives you two different major versions, and every Prisma 7 tutorial breaks at the first command.

I checked it on October 7, 2026 with a fresh install:

$ npm view prisma dist-tags.latest
8.0.0-rc.20
$ npm view @prisma/client dist-tags.latest
7.10.0

These are the Prisma 7 commands I ran against it, each in the CLI's new JSON output:

You ran	Prisma 8 RC answered
`npx prisma generate`	No command registered for `generate`
`npx prisma migrate dev`	No command registered for `migrate`, did you mean `migration`?
`npx prisma db push`	No command registered for `push`, did you mean `update`?
`npx prisma validate`	No command registered for `validate`

Check which CLI you have

npx prisma --version tells you straight away. Prisma 7 prints a table (prisma : 7.10.0, @prisma/client : 7.10.0 and so on). The 8 release candidate prints one line of JSON:

{"kind":"result","envelope":{"ok":true,"commandId":"version","result":{"version":"8.0.0-rc.20"},...}

If you see JSON, you're on Prisma 8.

The fix for an existing Prisma 7 app

Prisma 8 isn't final yet: Prisma's own release status page calls it a release candidate, with general availability expected in October 2026. The same page says Prisma 7 keeps getting bug fixes and security updates for 18 months after that. If you have a working Prisma 7 app, the move is a rewrite (no @prisma/client, a new schema format, new commands), not a version bump.

Pin the CLI to the same major version as your client:

npm i -D prisma@7

npm saves that as ^7.10.0, which stays on 7.x. Then the usual commands work again:

$ npx prisma generate
✔ Generated Prisma Client (7.10.0) to .\src\generated\prisma in 117ms
$ npx prisma migrate dev --name init
Datasource "db": PostgreSQL database "postgres", schema "public" at "localhost:55432"

✅ After the pin, generate, migrate dev and a real query (an upsert through @prisma/adapter-pg) all worked against Postgres 17.

Docker and CI: `npx prisma` without a version

This is where most of the breakage is. A Dockerfile or CI step that runs npx prisma generate in a place where Prisma isn't installed (a slim production image, a separate migration job) makes npx download whatever latest is. I ran it in an empty folder with only prisma/schema.prisma in it:

$ npx -y prisma generate
{"kind":"result","envelope":{"ok":false,...,"summary":"No command registered for `generate`",...}}

Public repos have been filing the same failure since early September: Docker images, Railway deploys, a self-hosted release script, and Prisma's own Claude Code plugin ("unpinned npx -y prisma mcp now resolves to 8.0.0").

Put the major version in the command itself:

npx -y prisma@7 generate

✅ In the same empty folder this printed ✔ Generated Prisma Client (7.10.0).

Better still, keep prisma in devDependencies with the ^7 range and install from your lockfile (npm ci) before running it. Then npx uses the local copy instead of downloading latest.

If you already ran `prisma init` on the new CLI

npx prisma init with 8.0.0-rc.20 doesn't create prisma/schema.prisma or .env. In my test it created:

a prisma.config.ts that imports definePrismaConfig and only lists AI agents,
.claude, .cursor, .agents and .devin folders with Prisma "skills" in them,
a postinstall script in package.json: prisma skills sync || exit 0.

That config file breaks the old CLI even after the fix above. With it in place, Prisma 7.10.0 refused to start:

Failed to load config file "D:\nk-repro\prisma-init" as a TypeScript/JavaScript module.
Error: TypeError: (0 , _config.definePrismaConfig) is not a function

Replace prisma.config.ts with a Prisma 7 config (Prisma 7 reads the connection URL from here, not from the schema):

import 'dotenv/config';
import { defineConfig, env } from 'prisma/config';

export default defineConfig({
  schema: 'prisma/schema.prisma',
  migrations: { path: 'prisma/migrations' },
  datasource: { url: env('DATABASE_URL') },
});

Then delete the postinstall line, and the four agent folders if you don't want them.

✅ With this config, Prisma 7.10.0 printed Loaded Prisma config from prisma.config.ts and ran migrate dev normally.

Watch out for the update banner

Once the fix above is in, the Prisma 7 CLI shows an "update available" box at the end of some commands. Mine ended with:

│  Run the following to update                            │
│    npm i --save-dev prisma@latest                       │
│    npm i @prisma/client@latest                          │

Running that puts you straight back on the release candidate. Ignore it until you decide to move to Prisma 8 on purpose.

Moving to Prisma 8 instead

If you're starting a new project and want Prisma 8, these are the replacements from Prisma's migration page. I confirmed that the old names fail on 8.0.0-rc.20, but I haven't built a project on Prisma 8, so treat this as a map, not tested steps:

Prisma 7	Prisma 8 (per Prisma's docs)
`prisma init`	`prisma orm init --write-env`
`prisma generate`	`prisma contract emit`
`prisma migrate dev`	`prisma db update`, or `prisma migration plan` then `prisma db migrate`
`prisma db push`	`prisma db init` (empty database) or `prisma db update`
`@prisma/client`	one package per database, e.g. `@prisma/orm-postgres`

What didn't work

❌ Reinstalling @prisma/client. It was never the problem: it installs 7.10.0, the version that works. The CLI is the part that moved.

❌ Deleting node_modules and the lockfile. That makes it worse. A clean npm i prisma resolves latest again and brings the release candidate straight back, unless the version is pinned.

❌ Pinning the CLI but keeping the generated prisma.config.ts. Prisma 7 crashed on it with the definePrismaConfig is not a function error above.

How this was tested

A fresh npm project on Windows 11 with Node 24.14.0, created with npm i -D prisma and npm i @prisma/client on October 7, 2026, which installed prisma 8.0.0-rc.20 and @prisma/client 7.10.0. Every Prisma 7 command above was run against that CLI, then again after the fix, against Postgres 17 in Docker. The CI case was a folder containing only prisma/schema.prisma and .env, with nothing installed, running npx -y prisma generate and then the version-pinned command from the Docker section. npm dist-tags can change at any time: when Prisma 8 reaches its final release, latest will point to it for good, and the fix above stays the way to keep a Prisma 7 app running.

The code for every case above is public, so you can run it yourself: prisma-init and prisma-ci in nk-repro.

Originally published, with updates as new versions ship, at nilaykabariya.blog. Written with AI assistance; every error and fix was reproduced on a real machine before it was written up.

How I Built a Free, Self-Hosted Pipeline That Auto-Generates Faceless YouTube Shorts

nils44344 — Sat, 23 May 2026 13:35:32 +0000

Every "AI YouTube" tutorial ends the same way: sign up for ChatGPT Plus, then ElevenLabs, then Pictory, then n8n Cloud. Add it up and you're paying $75–100/month before you've made a single video — let alone a single dollar.

I didn't want a subscription stack. I wanted something that ran on my own machine, used free tiers and local models, and that I actually owned. So I built it, and I just open-sourced it under MIT.

It's called FreeFaceless, and it takes one command to go from nothing to an uploaded Short:

script → voiceover → captions → b-roll → assembled video → YouTube upload

Repo: https://github.com/nils44344/FreeFaceless

Here's how each stage works — and the one bug that cost me an evening.

The orchestration

The whole thing is a linear pipeline. Here's the heart of it (trimmed):

def run_once(publish_at=None, upload_to_youtube=True):
    data = script.generate()                          # 1. Groq writes the script
    voice_mp3 = voice.synth(data["full_text"], ...)   # 2. edge-tts voiceover
    words = captions.transcribe_words(voice_mp3)      # 3. local Whisper timing
    scenes = visuals.fetch_for_scenes(data["scenes"]) # 4. Pexels b-roll
    ass = captions.write_ass(words, ...)              # 5. caption file
    final = assemble.build(scenes, voice_mp3, ass, …) # 6. ffmpeg
    if upload_to_youtube:
        upload.upload_video(final, data["title"], …)  # 7. YouTube Data API

Every stage is its own module, and everything is driven by a single config.yaml — so changing the niche, voice, or caption style is an edit, not a code change.

1. Script generation — Groq (free tier)

Groq's free tier serves Llama 3.3 70B fast, and it's OpenAI-compatible, so the official openai SDK works by just pointing the base URL at Groq:

from openai import OpenAI
client = OpenAI(api_key=GROQ_API_KEY, base_url="https://api.groq.com/openai/v1")

resp = client.chat.completions.create(
    model="llama-3.3-70b-versatile",
    response_format={"type": "json_object"},  # forces clean JSON
    messages=[{"role": "system", "content": SYSTEM_PROMPT}, ...],
)

The prompt asks for a hook + 4–6 facts + a CTA, returned as JSON with per-scene visual_query strings I can feed straight to stock search. JSON mode means no fragile regex parsing.

2. Voiceover — edge-tts (free, no key)

edge-tts exposes Microsoft's neural voices for free, no API key:

import edge_tts
communicate = edge_tts.Communicate(text, "en-US-ChristopherNeural", rate="-12%")
await communicate.save("voice.mp3")

The quality is genuinely good enough for faceless content, and there are dozens of voices/accents to match the niche.

3. Word-level captions — faster-whisper (local)

This is the part most paid tools charge per-minute for. faster-whisper runs locally on CPU and gives word-level timestamps, which I turn into karaoke-style captions:

from faster_whisper import WhisperModel
model = WhisperModel("base", device="cpu", compute_type="int8")
segments, _ = model.transcribe("voice.mp3", word_timestamps=True)

Then I write an ASS subtitle file, 3 words at a time, in a big bold style — the look every Shorts channel uses. (FreeFaceless ships the open-licensed Anton font so it works out of the box.)

4. B-roll — Pexels (free API)

Each scene's visual_query becomes a Pexels Videos search, pulling vertical clips. Free API, generous limits.

5. Assembly — ffmpeg

ffmpeg crops every clip to 1080×1920, concatenates them to match the voiceover length, overlays the audio, and burns in the captions:

"-vf", f"subtitles='{ass_path}':fontsdir='{fonts_dir}'"

6. Upload — YouTube Data API

OAuth desktop flow, token cached after the first browser login, then every future run refreshes silently. Supports immediate or scheduled publishing.

The bug that cost me an evening: SSL on Windows

On my machine, every HTTPS call died with CERTIFICATE_VERIFY_FAILED. The culprit: antivirus doing TLS interception with a custom root cert that Python's bundled certifi doesn't know about. The fix is one import, before any network client is built:

import truststore
truststore.inject_into_ssl()  # use the OS cert store instead of certifi

If you build anything network-heavy on Windows, keep this in your back pocket.

Honest limitations

Free tiers are rate-limited. This is built for one channel on a normal schedule, not bulk farms. Push it hard and you'll hit limits.
Windows-first. The Python core runs anywhere; the helper scripts are PowerShell. Cross-platform PRs very welcome.
It's a production tool, not a money machine. It automates making videos. Views and revenue depend on your content and the algorithm — no tool changes that.

Try it / contribute

The repo has a full setup guide (including the Google OAuth walkthrough, which is the only fiddly part):

https://github.com/nils44344/FreeFaceless

If it's useful, a star helps other people find it — and I'd genuinely love feedback, especially on making the setup smoother for non-developers and getting it running on macOS/Linux.

DEV Community: nils44344

Gemini 2.5 Flash "no longer available to new users" (404)

The model list doesn't warn you

The fix

Don't jump straight to the suggested model

What didn't work

How this was tested

Prisma P1001: Can't reach database server at localhost:5432

Step 1: find out which one you have

Nothing is listening on that port

Docker: localhost and service names

No answer at all: firewalls, IPs and Supabase

Something is listening, but it isn't Postgres

Prisma 7 doesn't always say P1001

What didn't work

How this was tested

Gemini API 429 RESOURCE_EXHAUSTED: why your limit is 0

limit: 0: the model isn't in your tier

Per-minute limit: wait the time it gives you

Daily limit: it resets at midnight UTC, not Pacific time

Not a 429: "This model is currently experiencing high demand"

What didn't work

How this was tested

Supabase error 42501: new row violates row-level security policy

Which policy is missing

.insert().select() needs a SELECT policy too

You're not signed in (yet)

user_id isn't sent, so the check fails

Upsert: the "(USING expression)" version

Storage uploads

"permission denied for table": the October 30 change

What didn't work

How this was tested

Fix: @prisma/client did not initialize yet (Prisma 6 and 7)

The fix

On Windows, the install didn't generate for me

npm ci --ignore-scripts (and CI templates that use it)

npm 12 blocks Prisma's install script

npm i prisma gave you Prisma 8

Prisma 7 throws different errors

What didn't work

How this was tested

Next.js 16.3 vulnerabilities: which version is patched?

What npm audit says at each version

Which release fixed what

npm audit fix doesn't do what you'd expect

next upgrade crashes on Windows

What's new in 16.4.0

What didn't work

How this was tested

prisma generate not working: "No command registered" (Prisma 8)

Check which CLI you have

The fix for an existing Prisma 7 app

Docker and CI: npx prisma without a version

If you already ran prisma init on the new CLI

Watch out for the update banner

Moving to Prisma 8 instead

What didn't work

How this was tested

How I Built a Free, Self-Hosted Pipeline That Auto-Generates Faceless YouTube Shorts

The orchestration

1. Script generation — Groq (free tier)

2. Voiceover — edge-tts (free, no key)

3. Word-level captions — faster-whisper (local)

4. B-roll — Pexels (free API)

5. Assembly — ffmpeg

6. Upload — YouTube Data API

The bug that cost me an evening: SSL on Windows

Honest limitations

Try it / contribute

`limit: 0`: the model isn't in your tier

`.insert().select()` needs a SELECT policy too

`user_id` isn't sent, so the check fails

`npm ci --ignore-scripts` (and CI templates that use it)

`npm i prisma` gave you Prisma 8

Docker and CI: `npx prisma` without a version

If you already ran `prisma init` on the new CLI