DEV Community: Perufitlife

How to let Claude schedule your social media posts (MCP, step by step)

Perufitlife — Thu, 01 Oct 2026 10:01:02 +0000

Disclosure: I'm Renzo, and I build PostWire, the MCP server used here. It has a free plan. The same steps work with any MCP server that exposes scheduling tools; the tool names will differ.

Claude can't post to LinkedIn or Bluesky on its own. It has no access to your accounts. It can once you connect an MCP server (Anthropic calls these connectors) that holds those connections and exposes tools like "schedule this post". This tutorial sets that up, schedules a post, plans a week of posts, and cancels one. Along the way it shows the actual tool calls Claude makes, so you can do the same from your own agent.

Everything below was run on Oct 1, 2026 against PostWire's hosted server with a test account.

Step 1: Add the server

In Claude (web, desktop, mobile): PostWire is in Claude's connector directory. Search for "PostWire", press Connect, and sign in with your email. You get a 6-digit code; there's no password and no card.

In Claude Code, one command:

claude mcp add --transport http postwire https://postwire.io/api/mcp

Without a key, Claude Code signs you in with OAuth: run /mcp inside Claude Code and pick postwire. To use an API key instead (dashboard → API & MCP → Copy key):

claude mcp add --transport http postwire https://postwire.io/api/mcp \
  --header "Authorization: Bearer pw_live_your_key"

Check it:

$ claude mcp list
postwire: https://postwire.io/api/mcp (HTTP) - ✔ Connected

The hosted server has 15 tools. The ones this tutorial uses are create_connect_link, generate_posts, schedule_post, plan_week, list_scheduled_posts and cancel_scheduled_post.

Step 2: Connect the networks you post to

Ask: "Connect my LinkedIn." Claude calls create_connect_link:

{ "name": "create_connect_link", "arguments": { "platform": "linkedin" } }

and gets back a link that's valid for one hour:

{ "url": "https://postwire.io/connect/#…", "expires_in": 3600, "platform": "linkedin" }

You open it and sign in on LinkedIn itself. Claude never sees a password. The networks you can connect are TikTok, Instagram, YouTube, LinkedIn (personal profiles), Facebook Pages, Bluesky, Mastodon, Telegram and Discord. X, Threads, Reddit and Pinterest aren't available.

Step 3: Tell Claude your time zone once

Scheduling needs an exact time with an offset (run_at, ISO 8601, up to 365 days ahead). Say "I'm in New York" once and Claude will turn "Friday at 9" into 2026-10-09T09:00:00-04:00.

Step 4: Schedule one post

"Write a short post announcing our autumn menu for LinkedIn and Bluesky and schedule it for Friday 9:00."

Claude first calls generate_posts, which returns one draft per network and publishes nothing. It shows you the drafts. After you approve, it calls:

{
  "name": "schedule_post",
  "arguments": {
    "run_at": "2026-10-09T09:00:00-04:00",
    "platforms": ["linkedin", "bluesky"],
    "per_platform": { "linkedin": { "text": "…" }, "bluesky": { "text": "…" } },
    "label": "Menu launch"
  }
}

The answer (trimmed, from my run against a test channel):

{
  "ok": true,
  "scheduled": {
    "id": "0f8b4368-…",
    "run_at": "2026-10-09T13:00:00+00:00",
    "status": "queued",
    "label": "Menu launch"
  },
  "message": "Scheduled for 2026-10-09T13:00:00.000Z to …"
}

Two details matter here:

PostWire's servers publish it, so the chat and your laptop can be closed at 9:00.
The checks happen now, not at 9:00. If a network isn't connected, or a network needs a video and the post has none, schedule_post refuses immediately with a not_connected or media_required code. You find out while you're still in the conversation.

Step 5: Or plan the whole week

"Plan the next 5 days of posts about our autumn menu and the farmers behind it, LinkedIn and Bluesky, 9 am New York time."

Claude calls plan_week:

{
  "name": "plan_week",
  "arguments": {
    "topic": "our new autumn menu and the farmers behind it",
    "platforms": ["linkedin", "bluesky"],
    "days": 5, "hour": 9, "timezone": "America/New_York"
  }
}

It writes one post per day, each from a different angle and each in the format of its network, and queues them starting tomorrow. In my run with "days": 2 (to a test Discord channel) it queued 2026-10-02T13:00:00Z and 2026-10-03T13:00:00Z (9:00 in New York). Day one opened with a lesson ("building our autumn menu taught us something we didn't expect…") and day two with an opinion ("hot take 🍂 most people scroll past a new menu…").

Limits you should know about:

plan_week is for text networks. It refuses TikTok, Instagram and YouTube, because those need a video or photo. Schedule those one post at a time.
Each day uses one AI draft. The free plan allows 15 a day and 30 posts a month, and a post to two networks counts as 2.
If the week doesn't fit in the month's posts, the extra days are saved as held. They're never published on the current plan, and get scheduled if you upgrade.

Step 6: Check and cancel

"What's scheduled?" → list_scheduled_posts returns each post's id, time, networks and status (queued, done, failed, canceled…).

"Cancel Friday's post." →

{ "name": "cancel_scheduled_post", "arguments": { "id": "0f8b4368-…" } }
→ { "ok": true }

A post can be cancelled until it starts publishing. The same queue shows up in the dashboard, with Reschedule and Cancel buttons.

Videos: the attachment problem

If you attach a video in the chat, it never reaches an MCP server. Claude can't hand it over. Instead it calls create_upload_link:

{ "url": "https://postwire.io/upload/#…", "expires_in": 86400, "max_bytes": 1073741824 }

You open that link on the device that has the file and upload it (up to 1 GB). Claude then calls get_uploaded_file to get its media_url and uses that as video_url.

One caveat I found while writing this: schedule_post has no privacy field today. A TikTok or YouTube video scheduled through it goes out private (with no privacy value, PostWire posts to TikTok as private, and YouTube uploads default to private) unless the connected account's default visibility is set to public. For YouTube you can set that in the dashboard under Accounts. For a public video now, post_to_social accepts "privacy": "public". For a public video later, use the REST call below, which passes privacy through.

Without Claude: the same thing over REST

Any agent framework (or a cron job) can do the same with one HTTP call:

curl -X POST https://postwire.io/api/schedule \
  -H "Authorization: Bearer $POSTWIRE_API_KEY" -H "Content-Type: application/json" \
  -d '{"run_at":"2026-10-09T09:00:00-05:00","platforms":["linkedin","bluesky"],"text":"Launch day.","label":"Launch"}'

GET /api/schedule lists the queue and DELETE /api/schedule/<id> cancels a post. If a network isn't connected, you get 400 with "code": "not_connected" and the list of missing networks.

When this is the wrong tool

If you need X, Threads, Pinterest or Reddit, PostWire doesn't publish there.
LinkedIn is personal profiles only, not Company Pages.
Claude asks before it publishes, and it should keep doing that. Every post_to_social call is a real post on a real account, so approve the exact text.

Configs for Claude Desktop, Cursor, VS Code and Windsurf, plus runnable curl, Node and Python versions of the REST calls, are in the Perufitlife/postwire-examples repository on GitHub. The step-by-step guide, with the FAQ, is here: How to schedule social media posts with Claude.

How to post one video to TikTok, Instagram Reels and YouTube Shorts from n8n (works on n8n Cloud)

Perufitlife — Thu, 01 Oct 2026 10:00:54 +0000

Disclosure: I'm Renzo, and I build PostWire, the posting API this tutorial uses. It has a free plan, and the workflow below runs on it. If you'd rather call each network's API yourself, the first section explains what that involves.

You have a vertical video and you want it on TikTok, Instagram Reels and YouTube Shorts, posted from n8n, ideally with a caption that suits each network instead of one caption pasted three times.

n8n has no core node that publishes to TikTok. Calling each network's API yourself means:

TikTok: a developer app with the Content Posting API. Until TikTok audits it, it can only post privately (SELF_ONLY), to at most 5 users in 24 hours, and those accounts must be private.
Instagram: a Meta app that has been through App Review, then for each post you create a media container, poll until the video has processed, and publish it.
YouTube: a Google Cloud project, with Google verification of the youtube.upload scope before strangers can authorize it.

The shortcut is to call an API that already has those approvals. Below, that means four nodes and two HTTP requests. They only use the core HTTP Request node, so the workflow runs on n8n Cloud too, where community nodes that n8n hasn't verified can't be installed.

What you'll build

Manual Trigger → Set (idea, video, networks) → HTTP Request: /api/generate → HTTP Request: /api/post

You give it one idea and one video link.
/api/generate writes a TikTok caption, an Instagram caption, and a YouTube title, description and tags. Nothing is published at this step.
/api/post publishes the video to all three networks in one call, each with its own text, and returns one result per network.

I ran this exact workflow on Oct 1, 2026 in n8n 2.40.7 against the live API. The output further down comes from that run.

Before you start

n8n (Cloud or self-hosted).
A free PostWire account: one brand, 30 posts a month, no card. One video posted to three networks counts as 3 posts.
A vertical MP4 at a public URL that points straight at the file. A Google Drive or Dropbox share link won't work, because it opens a web page, not the file. (If your video isn't public, see "No public URL?" below.)

Step 1: Connect the three accounts

Create the account at postwire.io, open Accounts, press Connect on TikTok, Instagram and YouTube, and sign in on each network. Instagram needs a Business or Creator account; "Log in with Instagram" works without a Facebook Page. You don't need a TikTok, Meta or Google developer app of your own.

Then open API & MCP and press Copy key. The key starts with pw_live_.

Step 2: One credential in n8n

Credentials → Add credential → Header Auth:

Name: Authorization
Value: Bearer pw_live_your_key

Both HTTP Request nodes use it.

Step 3: The input node

Add a Set node called Your idea, video and platforms with four fields:

Name	Type	Value
`idea`	String	`Announce that our AI meal planner now builds a full week of recipes from one photo of your fridge. Friendly, build-in-public tone.`
`video_url`	String	`https://example.com/your-vertical-video.mp4`
`platforms`	Array	`{{ ["tiktok", "instagram", "youtube"] }}`
`brand_voice`	String	`Plain language, first person, no hype, at most one emoji.`

In a real workflow these come from the previous node: a new file in a folder, a row marked "ready" in a sheet, or the output of an AI video step.

Step 4: Write a caption per network

Add an HTTP Request node:

Method: POST
URL: https://postwire.io/api/generate
Authentication: Generic Credential Type → Header Auth → the credential from step 2
Send Body: on, Body Content Type JSON, Specify Body Using JSON:

{{ JSON.stringify({ prompt: $json.idea, platforms: $json.platforms, media_url: $json.video_url, brand_voice: $json.brand_voice }) }}

It takes 10–30 seconds. Here is what came back in my run (YouTube trimmed):

{
  "drafts": {
    "tiktok": {
      "text": "One photo of your fridge → a full week of recipes. No more \"what do I even make?\" 😅 We just shipped this in our meal planner and I'm honestly still a bit shocked it works this well. #mealplanning #AIcooking #buildinpublic #mealprep #foodtech Drop a 🙋 if you want early access.",
      "title": "We taught our AI to read your fridge 🧠"
    },
    "instagram": {
      "text": "One fridge photo. Seven days of recipes. 📸 We just shipped this — save this if you want to try it.\n\n#mealplanning #buildinpublic #AIcooking #mealprep #foodtech"
    },
    "youtube": {
      "text": "We just shipped a feature I've been wanting to build for a long time — our AI meal planner can now generate a full week of recipes f…",
      "title": "…",
      "tags": ["…"]
    }
  }
}

The three texts really are different. They're also not perfect: the brand voice asked for "at most one emoji" and the TikTok caption has two. Read the drafts before you publish anything unattended. The free plan allows 15 of these generations a day.

Step 5: Publish to all three

Add a second HTTP Request node with the same method, credential and body settings, URL https://postwire.io/api/post, and this body:

{{ JSON.stringify({ platforms: $('Your idea, video and platforms').item.json.platforms, video_url: $('Your idea, video and platforms').item.json.video_url, per_platform: $json.drafts, options: { tiktok: { privacy_level: 'SELF_ONLY' } } }) }}

per_platform is the drafts object from step 4, passed back unchanged. Each network gets its own text, and YouTube gets the title and tags too.

About privacy, before you go live. This body posts the TikTok video as private (SELF_ONLY) so a first test isn't public. YouTube uploads with no privacy value are private too. Instagram has no private mode: the Reel is public as soon as it posts. When you're ready, replace the options line with privacy: 'public', which makes both TikTok and YouTube public.

Step 6: Read the result

The answer has posted (how many networks published) and results, one per network. On success, each result has ok: true and the network's id. YouTube also returns a youtu.be link. TikTok returns status: "processing", because TikTok keeps processing the video after upload. GET https://postwire.io/api/post/status?platform=tiktok&id=<id> tells you when it's live.

My test account had no networks connected, so this is what my run returned. It also shows what a failure looks like:

{
  "posted": 0,
  "results": [
    {
      "ok": false,
      "platform": "tiktok",
      "error": "tiktok is not connected — open Accounts in the dashboard and connect it, then post again",
      "code": "not_connected",
      "what": "TikTok was not connected to your account when the post was sent.",
      "fix": "Connect TikTok in Accounts, or leave it out of the post. Only the networks you have connected can be published to."
    }
  ]
}

(Instagram and YouTube returned the same.) One network failing doesn't stop the others. Check posted, not just the HTTP status: the response is a 200 even when a network fails.

Making it safe to run unattended

Retries don't double-post. Add idempotency_key to the publish body, set to something unique per video (the file id, the sheet row). A retry with the same key is refused for 24 hours with 409 duplicate_post. That matters if you turn on n8n's "Retry On Fail". Without a key, an identical payload is still refused for 2 minutes. If nothing went out, the key is released, so a real retry still works.
Swap the trigger. Replace the Manual Trigger with a Google Drive, Google Sheets or Schedule trigger, and map idea and video_url from it.
Publish later. POST the same body plus run_at (ISO 8601 with offset, e.g. 2026-10-09T09:00:00-05:00) to https://postwire.io/api/schedule. The connections and media are checked when you schedule, not at 7 a.m. when the post is due.

No public URL?

If the video is a binary item in n8n (from a Drive download, an AI video node, a form upload), use three more HTTP Request nodes:

POST https://postwire.io/api/media/upload-url with {"content_type": "video/mp4", "size_bytes": <size>} returns an upload_url and a path.
PUT to that upload_url, Body Content Type n8n Binary File, field data. No auth header: the URL is signed.
GET https://postwire.io/api/media/finalize?path=<path> (with the credential) returns media_url, which you use as video_url.

Through n8n that path takes files up to 50 MB. From a script the API accepts up to 1 GB in parts.

Limits, honestly

TikTok, Instagram and YouTube never take a text-only post. They need a video (or photos for TikTok and Instagram).
PostWire covers TikTok, Instagram, YouTube, LinkedIn (personal profiles), Facebook Pages, Bluesky, Mastodon, Telegram and Discord. Not X, Threads, Reddit or Pinterest. If you need those, use another tool.
PostWire's own n8n community node (n8n-nodes-postwire, with a "Smart Distribute" option that does steps 4 and 5 in one node) isn't verified by n8n yet, so it installs on self-hosted n8n only. That's why this tutorial uses plain HTTP Request nodes.
PostWire publishes the file you give it. It doesn't edit or clip videos.

The importable workflow JSON, plus versions that start from Google Sheets, OneDrive and Veo 3.1, are in the Perufitlife/postwire-examples repository on GitHub. The full guide, with a comparison against Blotato, Upload-Post and calling TikTok's API directly, is here: n8n: post to TikTok, Instagram and YouTube in one node.

Supabase's Oct 30 grants change: the changelog's rollback reopens every table without RLS

Perufitlife — Sat, 26 Sep 2026 04:47:34 +0000

On October 30, 2026 Supabase stops auto-granting new objects in the public schema to anon, authenticated and service_role on every existing project. The five-week notice email went out on September 23, and since then the questions have been the same ones over and over: will my app break?, which tables?, what do I run?

Short answers: your running app does not break, the tables that get hurt are the ones you haven't created yet (or the ones you re-create from migrations), and the SQL you are most likely to run is the one that makes things worse.

This post covers what actually changes, what doesn't, the fix that quietly reopens every table without RLS, and how to write migrations that survive October 30 without exposing anything. Every Postgres behaviour below I reproduced on a real Postgres (18.3); the Supabase specifics are quoted from the changelog and from Supabase engineers in discussion #45329.

TL;DR

Existing tables keep their grants. Nothing that works today stops working on Oct 30. Supabase engineers confirmed this in the discussion thread.
New tables, views and sequences created in public after Oct 30 are born with no grants: supabase-js gets 42501 permission denied. That includes server code using the service_role key.
Replaying your migrations on a new project, a preview branch or supabase db reset hits this for every table your migrations create without an explicit GRANT.
The changelog's own rollback snippet is grant ... on all tables in schema public to anon, authenticated, service_role. On a table without RLS, that grant publishes every row to anyone holding your anon key.
Functions are not covered by the change. Postgres grants EXECUTE to PUBLIC by default, anon inherits it, and the per-schema revoke in the docs has no effect on that.
The durable fix: in the same migration that creates the object, write grants per table, per role, mirroring your RLS policies. Then add a CI check so the next migration can't regress.

What changes, exactly

Until now, a Supabase project shipped with default privileges that granted select, insert, update, delete on every new table in public to the three API roles. Create a table and it was reachable through PostgREST (and GraphQL) straight away, protected only by RLS, if you remembered to turn it on.

The change removes those default privileges. The official "opt in early" SQL is exactly this:

alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;

alter default privileges for role postgres in schema public
  revoke usage, select on sequences from anon, authenticated, service_role;

A few things to note:

"Tables" includes views. In Postgres, default privileges on tables apply to all relations, so a new view is born without grants too.
Sequences are separate. A table grant does not cover the sequence behind a serial column (more on that below).
service_role loses the automatic grant as well. service_role bypasses RLS, not privileges. If your backend or Edge Function uses supabase-js with the service key against a new table, it gets the same 42501. Only direct Postgres connections (psql, an ORM with a connection string) are unaffected, because they don't go through the Data API roles.
Not affected: storage, auth, realtime and custom schemas keep their current defaults (changelog FAQ).

What you'll see

A missing grant is not a silent empty result. PostgREST answers with:

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

over HTTP 401 for anon requests and 403 for authenticated ones. A useful rule of thumb when debugging:

Symptom	Meaning
`42501 permission denied for table`	The role has no grant. RLS was never even evaluated.
`42501 permission denied for sequence`	The table grant is there, the `serial` sequence grant isn't.
`[]` (empty array, 200)	Grant is fine, RLS returns no rows for this role.
`PGRST205` table not found in schema cache	PostgREST hasn't reloaded yet: `notify pgrst, 'reload schema';`

What does NOT break

This is the part the email made scarier than it is. From the changelog: "Existing tables are not affected in your project, they keep their current grants and stay reachable." In the discussion, a user asked whether existing tables on existing projects are "guaranteed to retain their current grants and will never be silently revoked by the October 30 rollout", and a Supabase engineer answered: "Both are correct."

So if your project is live and you never create another table, nothing happens on October 30.

That is also the uncomfortable part: every table that is over-exposed today stays over-exposed. The change only protects what you create next.

Where it actually bites

The next migration that creates a table. It deploys fine, and the first request from the app fails with 42501. With AI agents generating migrations, this tends to show up as "the feature works locally and fails in production".
Replaying migrations anywhere fresh. A new project per customer, a staging environment, a preview branch, a teammate's supabase db reset. Your old migrations never needed GRANT statements, so on a project without the old defaults every table they create is unreachable. As one user put it in the thread: "any new instance of that app that you deploy will fail to work because the old migration scripts didn't grant the required privileges."
Local and cloud disagree. CLI v2.102.0 added [api] auto_expose_new_tables = false to config.toml so db reset mimics the new cloud behaviour, but it is a temporary aid scheduled for removal on 2026-10-30, and at least one user reported branches failing to clone with 'api' has invalid keys: auto_expose_new_tables. If you leave it unset, local keeps auto-exposing and hides the problem until production.

The fix that reopens everything

When a table suddenly answers 42501, the fastest thing that makes the error go away is a bulk grant. It is literally what the changelog FAQ gives as the rollback:

grant select, insert, update, delete on all tables in schema public to anon, authenticated, service_role;
grant usage, select on all sequences in schema public to anon, authenticated, service_role;

And in the discussion, a Supabase engineer suggested the same bulk grant as a one-off migration for existing tables, plus grant execute on all functions in schema public to anon, authenticated, service_role. To be fair, that reply also says per-object grants are "the better answer for most projects". But the bulk version is the one that gets copy-pasted, and the email template's example grants select to anon too.

The bulk grant is only safe if every table in public has RLS enabled and correct policies. On any table where RLS is off, it means this:

create table public.secrets (email text);
insert into public.secrets values ('a@b.c');

grant select, insert, update, delete on all tables in schema public
  to anon, authenticated, service_role;

set role anon;
select * from public.secrets;
--  email
-- -------
--  a@b.c

Anyone holding the anon key (it's in your JS bundle, by design) can read, insert, update and delete every row through /rest/v1/secrets. RLS off plus a grant is exactly the pattern behind the TechCrunch report from September 25: UpGuard found around 16,000 Supabase databases exposing personal data. The October 30 change is Supabase trying to make that harder by default. A bulk grant written to silence an error undoes it.

The same goes for the "restore the old defaults" option (alter default privileges ... grant ... to anon, authenticated, service_role): it puts every future table back on the API before anyone has written a policy for it.

Writing migrations that survive Oct 30

The rule the changelog itself states is "Treat these three steps as a unit": grant, enable RLS, add policies, in the same migration that creates the table. The part I'd add: grant each role only what its policies actually use. A grant to a role with no matching policy just widens the surface for the day someone disables RLS.

Tables

create table public.orders (
  id bigint generated always as identity primary key,
  user_id uuid not null references auth.users (id) default auth.uid(),
  total_cents int not null,
  created_at timestamptz not null default now()
);

alter table public.orders enable row level security;

create policy "own orders: read" on public.orders
  for select to authenticated using ((select auth.uid()) = user_id);
create policy "own orders: create" on public.orders
  for insert to authenticated with check ((select auth.uid()) = user_id);

-- grants mirror the policies: authenticated can select/insert, anon gets nothing
grant select, insert on table public.orders to authenticated;
-- backend / Edge Functions using the service key
grant select, insert, update, delete on table public.orders to service_role;

A few decisions this forces you to make explicitly, which is the point:

anon only where a policy is written to anon (a public catalogue, a waitlist insert). If no policy mentions anon, don't grant it.
service_role only on tables your server code touches through the Data API. A table only reached through a direct connection doesn't need it.
Tables that should never be on the API (audit logs, internal queues): no grants at all, or an explicit revoke all on table public.x from anon, authenticated, service_role;.

Sequences: `serial` vs `identity`

This one catches people because it only fails on insert, and only for the API roles:

create table public.s (id serial primary key, v text);
create table public.i (id bigint generated always as identity primary key, v text);
grant select, insert on public.s, public.i to authenticated;

set role authenticated;
insert into public.s (v) values ('a');
-- ERROR: permission denied for sequence s_id_seq
insert into public.i (v) values ('a');
-- ok, id = 1

A serial column is a plain sequence plus a nextval() default, so the inserting role needs usage on the sequence:

grant usage, select on sequence public.s_id_seq to authenticated, service_role;

An identity column's sequence is internal to the table and doesn't need a separate grant. For new tables, generated always as identity is one less thing to forget. For existing serial tables that you replay from migrations, add the sequence grant.

Views

Views are born without grants too, and they have a second trap: by default a view runs with its owner's privileges, so it bypasses the RLS of the tables it reads. If you grant a view to anon or authenticated, make it respect the caller's RLS (Postgres 15+):

create view public.order_totals with (security_invoker = on) as
  select user_id, sum(total_cents) as total_cents from public.orders group by user_id;

grant select on public.order_totals to authenticated;

Materialized views can't have RLS at all: keep them off anon/authenticated and expose them through a function or a server route instead.

Functions: the part Oct 30 doesn't touch

Postgres grants EXECUTE on every new function to PUBLIC, and anon/authenticated are members of PUBLIC. So every function you create in public is callable as /rest/v1/rpc/<name> with the anon key unless you revoke it. With security definer, it runs with its owner's rights and skips RLS entirely.

The Securing your API docs suggest alter default privileges for role postgres in schema public revoke execute on functions from public;. That statement doesn't have the documented effect (supabase#49338, and a reproduction in the discussion). The reason is a Postgres rule: per-schema default privileges can only add to the global defaults, never remove from them. The built-in PUBLIC execute is a global default, so a revoke scoped in schema public changes nothing:

alter default privileges for role postgres in schema public
  revoke execute on functions from public;
create function public.f1() returns int language sql as 'select 1';
select has_function_privilege('anon', 'public.f1()', 'execute');   -- true

alter default privileges for role postgres
  revoke execute on functions from public;                          -- no "in schema"
create function public.f2() returns int language sql as 'select 2';
select has_function_privilege('anon', 'public.f2()', 'execute');   -- false

The global form works on plain Postgres, but it applies to every schema, and I haven't verified it against the extra default ACLs a hosted Supabase project carries. The approach that works everywhere is explicit and per function:

create function public.admin_stats() returns json
language sql security definer set search_path = '' as $$
  select json_build_object('users', (select count(*) from auth.users));
$$;

revoke execute on function public.admin_stats() from public, anon;
grant execute on function public.admin_stats() to service_role;

Two details:

revoke ... from anon alone is not enough: anon still gets it through PUBLIC. Revoke from both.
Helper functions used inside RLS policies (is_org_member(org_id) and the like) need execute for the role the policy applies to, usually authenticated. Revoke anon, keep authenticated.

And always pin search_path on security definer functions.

Audit what's already exposed

Since existing tables keep their grants, run these once in the SQL editor to see what is on the API today.

Tables reachable by anon or authenticated with RLS off (this is the dangerous list):

select c.oid::regclass as relation,
       has_table_privilege('anon', c.oid, 'select,insert,update,delete') as anon,
       has_table_privilege('authenticated', c.oid, 'select,insert,update,delete') as authenticated
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind in ('r', 'p')
  and not c.relrowsecurity
  and (has_table_privilege('anon', c.oid, 'select,insert,update,delete')
    or has_table_privilege('authenticated', c.oid, 'select,insert,update,delete'));

Functions anon can call (look hard at every security_definer = true):

select p.oid::regprocedure as function, p.prosecdef as security_definer
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
  and has_function_privilege('anon', p.oid, 'execute')
order by p.prosecdef desc;

Views granted to anon that don't enforce the caller's RLS:

select c.oid::regclass as view
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind = 'v'
  and coalesce(array_to_string(c.reloptions, ','), '') !~ 'security_invoker=(on|true|1|yes)'
  and has_table_privilege('anon', c.oid, 'select');

The Security Advisor and the "Data API exposure" badge in the Table Editor cover part of this too.

Make local match production now

Don't wait for October 30 to discover which migrations lack grants. Either set this in supabase/config.toml (CLI ≥ 2.102.0, remember it's temporary):

[api]
auto_expose_new_tables = false

or, more durable, put the same revoke the dashboard runs into an early migration so every environment behaves like post-Oct-30 production:

alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;
alter default privileges for role postgres in schema public
  revoke usage, select on sequences from anon, authenticated, service_role;

Then supabase db reset and click through the app. Every 42501 is a grant you were silently relying on.

Catch it in CI

Remembering all of the above on every PR is the part that doesn't scale, especially when an agent writes the migration. I wrote an open-source (MIT) linter that replays your supabase/migrations SQL in order, with no database and no credentials, and flags:

tables/views with no grant (unreachable after Oct 30, and already on any fresh project or branch);
tables granted to anon/authenticated with RLS off;
bulk grant ... on all tables ... to anon and alter default privileges ... to anon;
security definer functions callable by anon, including through PUBLIC;
views without security_invoker, serial sequences missing usage, security definer without search_path.

For each finding it proposes the least-privilege grant based on your policies. Drop this into .github/workflows/supabase-grants.yml:

name: Supabase grants lint
on:
  pull_request:
    paths: ['supabase/**']
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Perufitlife/supabase-security-skill@main
        with:
          mode: migrations   # reads supabase/migrations, no project ref, no token
          fail-on: high      # or: critical

You get inline annotations on the offending migration lines, a job summary, and a proposed migration uploaded as an artifact. To run it locally first:

npx -y github:Perufitlife/supabase-security-skill migrations

Honest limits: it's a replay of your SQL, not a Postgres, so it skips DO blocks, dynamic EXECUTE and anything created from the dashboard. It also can't know which tables you meant to be public: when it proposes a grant, read it. Mark intentional exceptions with -- supabase-security: ignore above the statement. Issues with the SQL that fools it are welcome: github.com/Perufitlife/supabase-security-skill.

Checklist before October 30

Run the three audit queries above. Fix anything with RLS off that anon can reach today. That exposure doesn't depend on the date.
Make local behave like post-Oct-30 production (config.toml or an early revoke migration) and db reset.
Add a migration with per-table grants for everything your app uses, mirroring your policies. Don't use on all tables.
Add usage on sequences behind serial columns the API inserts into.
revoke execute ... from public, anon on every function that isn't meant to be a public endpoint.
Put a check in CI so the next migration doesn't regress.
Update your AI agent's instructions (or the Supabase agent skill): grants + RLS + policies in the same migration, never a bulk grant.

If you'd rather have someone do this for you: I apply least-privilege grants, fix the RLS gaps and verify them on a branch, delivered as a pull request. There's also a free check that takes a public repo URL and emails you the report: supabase-security Oct 30.

Posting to TikTok from n8n: the App Review wall, and the way around it

Perufitlife — Mon, 31 Aug 2026 10:00:59 +0000

If you are trying to post to TikTok from n8n, Make, or your own code, you will hit this wall in roughly this order:

The credential connects fine.
The upload call fails.
You start TikTok's App Review.
App Review asks for a demo video of the working integration you cannot build yet.

That last one is the part that feels impossible. It isn't, but the way out is not obvious and the error messages actively point the wrong way. Here is what actually happens, from having gone through the audit and shipped against this API.

Sandbox first — you do not need App Review to get a token

You can get a real, working access token today. Add your own TikTok account as a target user in your app's sandbox, and the OAuth flow completes normally.

That is also the answer to the chicken-and-egg problem: you record the demo video in sandbox. Reviewers expect that. You are not required to have a live public integration before review — you are required to show the flow working, including the consent screen, which sandbox does.

If you are seeing Unable to sign without access token, that is not an App Review problem at all. It means no user access token is stored: either the authorization code flow never finished, or the token is not being attached to the request. Starting App Review will not fix it, and it costs you days.

The restriction nobody documents clearly

Here is the one that catches everybody, because the error names the symptom instead of the cause.

An unaudited app can only post as private. TikTok's enum for that is SELF_ONLY. If you send anything else — PUBLIC_TO_EVERYONE, or a friendly-looking "public" — the call fails with:

unaudited_client_can_only_post_to_private_accounts

Which reads like something is wrong with the account. Nothing is wrong with the account. The app has not passed audit yet.

And it is per creator, not just per app. Even after your app is audited, an individual creator's allowed levels depend on their own settings — a private account will not accept PUBLIC_TO_EVERYONE no matter what your app is allowed to do. So you cannot hardcode a privacy level and hope.

The API tells you, if you ask first:

POST /v2/post/publish/creator_info/query/
→ { "data": { "privacy_level_options": ["PUBLIC_TO_EVERYONE", "MUTUAL_FOLLOW_FRIENDS", "SELF_ONLY"], ... } }

Call that before every publish, and pick a level from what comes back. That single call turns a confusing rejection into a decision you can make.

One more, related: branded content cannot be posted as SELF_ONLY. If you set branded_content_toggle, you must also choose a non-private level. Two rules that individually make sense and together produce a contradiction you can only hit at runtime.

The chunk rules will bite you at specific file sizes

For FILE_UPLOAD, TikTok wants chunks between 5MB and 64MB, and the final chunk may exceed chunk_size (up to 128MB). Maximum total: 4GB.

The trap is arithmetic. If you compute total_chunk_count = ceil(size / chunk_size), you will eventually produce a final chunk under 5MB, and TikTok rejects it. It only happens at certain file sizes, which is a miserable way to find a bug.

Use floor, and let the last chunk absorb the remainder:

const chunk = 32 * 1024 * 1024;                    // inside 5–64MB
const total = size <= 64 * 1024 * 1024 ? 1 : Math.floor(size / chunk);
// last chunk = size - (total - 1) * chunk, which lands between 32MB and 64MB

I verified this against every size from 3MB to 1GB with a plain loop asserting each chunk against the documented bounds. Thirty seconds of test code for a bug that would otherwise look random.

What the demo video needs to show

Reviewers are strict about one thing in particular: the use case "auto-posting to my own account" gets scrutinised, because it is what spam looks like from the outside. Show the consent flow, show the user choosing what goes out, show the post appearing. Do not show a script publishing unattended — that is the shape they reject.

If you would rather not do any of this

A pre-audited service posts through its own approved app, so you skip review entirely. There are several — Blotato, Upload-Post, and PostWire, which is mine. I mention it because the alternative is the four-step wall at the top of this post, and it is fair to know that skipping it is an option.

What I would keep from this either way: call creator_info before you publish. Whether you go direct or through a service, the allowed privacy levels are a property of the creator at that moment, and asking is the only reliable way to know.

A user spent a day confirming an email that was already confirmed

Perufitlife — Thu, 27 Aug 2026 12:02:25 +0000

A user spent a day confirming an email address that was already confirmed, because my API kept telling him to.

He was right and my error message was wrong. Here is the shape of the bug, because I think it is common and almost invisible.

The report

He found me on LinkedIn — not through support, because my support address bounced, which is a second bug I will get to.

My account is connected, but the API keeps returning: "Confirm your email first". I've confirmed the email multiple times, but the verification state never updates.

My first instinct was that verification was broken. It wasn't. His account showed verified_at set to one minute after signup. He had confirmed it correctly, the first time, and everything since had been theatre.

The line

if (!account.verified_at || (account.key_scope || "full") !== "full")
  return res.status(403).json({ error: "Confirm your email first — we sent you a link." });

Two conditions, one message.

The first is "your mailbox is unproven". The second is "this key is a preview key and cannot publish". They are unrelated failures with completely different fixes, and for months every caller hitting either one got told to go check their email.

He had hit the second. At signup the dashboard hands you a preview key so you can look around before verifying, and he had — reasonably — copied that key straight into his n8n workflow. Verifying his email did not upgrade it. So the key stayed limited, the API kept refusing, and the message kept pointing at the one thing that was already fine.

You can watch him try in the database: seven login tokens between 18:08 and 18:51. That is somebody confirming an email over and over because a computer told him to, each time getting a fresh working key he had no reason to know he needed.

Two fixes, and the second is the one that matters

Say which thing is wrong.

function unverifiedError(account) {
  if (account?.verified_at) {
    return {
      error: "This is a preview key, which cannot publish. Your email is already confirmed — " +
             "open API & MCP in the dashboard and use the key shown there.",
      code: "preview_key",
    };
  }
  return { error: "Confirm your email first — we sent you a link.", code: "email_unverified" };
}

Then remove the situation entirely. A better message would still have left him editing config. The preview key is limited for exactly one reason: we do not know the mailbox is his. The moment he proves it, that reason is gone — and the key he already pasted into n8n is the one that should start working.

export async function markVerified(accountId) {
  await db().from("pw_accounts").update({ verified_at: new Date().toISOString() })
    .eq("id", accountId).is("verified_at", null);
  await promotePreviewKeys(accountId);      // the reason for the restriction just expired
}

His existing setup now works without him touching anything.

The part I find uncomfortable

This bug was invisible from the inside. No exception, no 500, no alert. The API answered 403 with a clear, well-written, grammatically perfect sentence — that happened to be about the wrong problem. Every dashboard I had was green.

It surfaced because one user went out of his way to find me on a social network after his email to support@ bounced. That address appeared in eight places on my site and had never existed: the domain forwards mail, and nobody ever created the alias. So the one person motivated enough to report it had to work for the privilege.

I have since checked, and his was the only preview key in that state in the entire database. The bug found the one user it could hurt, and he still had to fight through a broken support channel to tell me.

What I would take from it

An error that covers two causes will send someone to fix the wrong one. They will repeat it, because nothing changes, and conclude your product is broken. Name the specific cause.
A restriction should expire when its reason does. If you gate something on an unproven condition, lift the gate the instant the condition is proven — including on credentials already issued.
Test the address on your own contact page. Mine bounced for months while I printed it in eight places.

I write PostWire, which publishes one draft natively to every social network. He was trying to post TikTok videos from n8n, which is exactly what it is for, and it told him to check his email instead.

A 100MB video used 460MB of RAM in my serverless function

Perufitlife — Wed, 26 Aug 2026 13:52:32 +0000

A 100MB video took 460MB of RAM in my serverless function. A 1GB one killed it outright. The fix was not more memory — it was never holding the file at all.

Here are the actual numbers, because I assumed the wrong bottleneck for weeks.

The symptom

My app forwards videos to TikTok and YouTube on a user's behalf. It had a hard 80MB limit on incoming video URLs, and the error message said so:

media too large (max 80MB)

TikTok accepts 4GB. YouTube accepts far more. So the ceiling was mine, and someone was going to ask why — which is exactly what happened.

My assumption: the function has a 60-second window, and video is big, so 80MB must be roughly what fits in the time. Reasonable. Wrong.

Measuring instead of guessing

I put a temporary probe in the function that downloads a URL and reports size, wall time and memory.

const t0 = Date.now();
const r = await fetch(url);
const buf = Buffer.from(await r.arrayBuffer());
res.json({
  mb: buf.length / 1048576,
  seconds: (Date.now() - t0) / 1000,
  rss_mb: process.memoryUsage().rss / 1048576,
});

Three runs, three surprises:

test	result
function that sleeps 70s	dies at 60.5s — so the platform limit was real and exact
download 100MB	1.3 seconds — about 77 MB/s
memory while holding that 100MB	460 MB RSS
download 1GB	`FUNCTION_INVOCATION_FAILED`

The bandwidth number is the one that reframed everything. 100MB arrives in 1.3 seconds. Even a full gigabyte is about 13 seconds of transfer inside a 60-second budget. Time was never the constraint.

Memory was. And notice the ratio: a 100MB file cost 460MB of resident memory — roughly 4.5×. That is because Buffer.from(await r.arrayBuffer()) materialises the body twice: once as an ArrayBuffer, once as a copy in a Buffer. Add the runtime's own overhead and a 1GB file blows through a 1GB memory limit long before it finishes.

So the 80MB ceiling was not protecting me from the clock. It was protecting me from my own allocation, and it was set conservatively on top of that.

The fix: never hold the file

Both APIs accept chunked uploads. If you read from the source stream and push each chunk as soon as it is complete, peak memory is one chunk, regardless of whether the video is 50MB or 900MB.

const reader = response.body.getReader();
let pending = [], pendingLen = 0, sent = 0;

for (;;) {
  const { done, value } = await reader.read();
  if (done) break;
  pending.push(Buffer.from(value));
  pendingLen += value.length;

  if (pendingLen >= CHUNK) {
    const body = Buffer.concat(pending, pendingLen);
    await uploadChunk(body, sent);        // PUT with a Content-Range
    sent += body.length;
    pending = []; pendingLen = 0;
  }
}
if (pendingLen) await uploadChunk(Buffer.concat(pending, pendingLen), sent);

Same probe, after the change:

	before (buffered)	after (streamed)
100 MB	460 MB RSS	132 MB RSS
1 GB	function died	142 MB RSS, 11.5 s

A full gigabyte now moves through in under twelve seconds while memory stays flat.

Three details that will bite you

1. Both APIs demand the exact byte count before you send a single byte.

TikTok's init call needs video_size. YouTube's resumable init needs X-Upload-Content-Length. You cannot discover the size while streaming — you need it up front, from the source's Content-Length header.

If the host does not send one, you cannot stream at all, and you are back to buffering. I kept that path and capped it explicitly, with an error that says why rather than just refusing:

that host does not report a file size, so the video has to be held in memory and cannot exceed 80MB

2. The chunk rules differ, and the last chunk is where it breaks.

TikTok: each chunk must be 5–64MB, and the final chunk may exceed chunk_size (up to 128MB). So the count is floor(size / chunk), and the last chunk absorbs the remainder.

Use ceil and you will eventually produce a final chunk under 5MB, which TikTok rejects. That bug only appears at certain file sizes, which is a miserable way to find it in production. I caught it with a plain loop over sizes from 3MB to 1GB, asserting each chunk against the documented bounds — thirty seconds of test code for a bug that would have looked random.

YouTube: every chunk except the last must be a multiple of 256KB. I use 32MB, which is 128 × 256KB. Because network reads arrive in irregular sizes (64KB, 17KB, sometimes 900 bytes), you have to accumulate to an aligned boundary and carry the remainder into the next chunk rather than sending whatever happens to have arrived.

3. YouTube answers 308 for every chunk but the last.

308 Resume Incomplete means success, keep going. But fetch reports response.ok === false for it. Treat it as an error and you abort the upload precisely when it is working:

if (put.status === 308) return false;   // more to send — this is success

What I would take from this

The instinct to blame the clock in a serverless function is strong, and it sent me down the wrong path for weeks. One probe with process.memoryUsage() and a timer settled it in ten minutes and pointed at a completely different fix.

Also: I removed that probe the moment it gave me the numbers. It did fetch(url) on any URL passed to it, which is an open SSRF — my server would fetch anything anyone asked it to. If you build one, validate the host or delete it the same day.

The limit went from 80MB to 1GB on both networks. I write PostWire, which publishes one draft natively to every social network, so a customer hitting an invented size cap was a promise I did not want to keep making.

6 social media API behaviours that are not in the docs

Perufitlife — Sun, 23 Aug 2026 11:36:48 +0000

Every social platform has a handful of API behaviours that are not in the quickstart. You meet them in production, usually at the worst moment, and the error message rarely tells you what is actually wrong.

These are the ones that cost us the most time building a multi-network publishing API. All of them are things we hit with real credentials against real accounts, not things we read.

1. TikTok rejects photos, and blames your video

Send a photo to TikTok's Content Posting API and you get:

tiktok requires a video_url

TikTok's Direct Post endpoint publishes video. Photo posts go through a separate flow (PHOTO post mode) that has its own approval. Most integrations discover this after a user has already scheduled twenty image posts.

What to do: validate media type per platform before you accept the post, not after. Our rule set is simply:

Network	Needs
TikTok	video, always
YouTube	video, always
Instagram	photo or video — never text-only
LinkedIn, X, Bluesky, Mastodon, Telegram	text alone is fine

2. `privacy_level: "public"` is not a thing

This one produces the most misleading error in the entire category:

privacy_level 'public' is not allowed for this creator

Read that as a user. It sounds like their account is restricted. It is not. The enum TikTok expects is:

PUBLIC_TO_EVERYONE
MUTUAL_FOLLOW_FRIENDS
FOLLOWER_OF_CREATOR
SELF_ONLY

public simply is not a value. The API told the truth and communicated the opposite of it.

There is a second trap behind it: an app that has not passed TikTok's audit can only post SELF_ONLY, no matter what the creator's own privacy options are. So during development every post is private, and the day your audit clears, the behaviour changes underneath you.

What to do: translate the obvious words (public, private, friends) into the platform enum, and when a level genuinely is not allowed, say why in your own error.

3. Access tokens die on very different clocks

Measured on live connections, not from the docs:

Network	Access token lifetime
TikTok	~24 hours
YouTube (Google OAuth)	1 hour
Meta Page tokens	long-lived — until the user changes their password

Every one of them refreshes silently if you built for it, and dies silently if you did not. The failure mode is nasty: your UI shows a green "Connected" badge for an account that stopped working three days ago, and the user only finds out when a scheduled post does not appear.

What to do: a status badge should be a question you asked just now, not a row you wrote once. Health-check the credential and say plainly when it needs reconnecting.

4. OAuth state cannot be raw base64

We spent a day on connections that failed only sometimes. The cause: we packed encrypted OAuth state as standard base64, which contains +, / and =. Those get URL-encoded — and in some redirect chains, double-encoded — so the callback could not decrypt what came back.

What to do: base64url for anything that travels in a query parameter. Node has it built in:

Buffer.concat([iv, tag, data]).toString("base64url");

5. Meta needs a Page, not a profile

Instagram publishing through the Graph API requires an Instagram Business account linked to a Facebook Page, and your app needs business_management to see the Page list. A personal Instagram account cannot be published to at all, and the error you get is about permissions rather than about account type — so people go hunting through their app review instead of their Instagram settings.

6. The approvals are the real work

The code for posting to any of these is an afternoon. The paperwork is not:

TikTok Content Posting API: rejected twice for us — once for an "Invalid Website URL" — approved seven days after the second fix.
Meta app review: seven permissions, approved clean on the first submission, but the Data Use Checkup is a separate recurring task.
Reddit: self-serve app creation for this use case is effectively gone; it is a Data Access Request and a wait.

If you are choosing between building this yourself and using something that already has the approvals, that list is the actual decision — not the HTTP calls.

I write these down as we hit them while building PostWire, a publishing API and MCP server for TikTok, Instagram, YouTube, LinkedIn, X, Bluesky, Mastodon, Telegram, Discord and Reddit. If you have hit one that is not on this list, I would genuinely like to hear it — the undocumented ones are the expensive ones.

Why I gave my income dashboard an MCP server instead of a mobile app

Perufitlife — Thu, 30 Jul 2026 00:21:32 +0000

I earn money from 23 different places.

Not big money. A few Stripe products, an Amazon affiliate link, some scrapers on a marketplace, an iOS app that makes $6.99 a month, the occasional PDF sale. The smallest one earned $0.01 last month. The biggest earned $224.

Added together, that's most of my income. And until recently I had no idea what the number was on any given day.

The problem isn't a missing dashboard

Revenue dashboards exist. Baremetrics, ChartMogul, ProfitWell — they're good products. They're also built for a completely different shape of business: one Stripe account, analysed deeply, priced from around $129/month for companies with a single product and a growth team.

My shape is the opposite. Many tiny streams, and — this is the part that matters — roughly half of them publish no earnings API at all.

I checked, carefully, because I wanted to automate it:

Amazon Associates: no OAuth, no public earnings API. The PA-API returns product data, not what you earned. There's an S3 data feed, granted at Amazon's discretion, and small publishers don't qualify.
Most ad networks: same story.
Apify (where I sell scrapers): earnings live in the console only. No API.

So any tool built purely on integrations is structurally blind to that money. Not "hasn't gotten around to it" — blind by architecture. You cannot integrate with an API that does not exist.

That's the gap I built into: automate what has an API, and make manual entry take ten seconds for everything else. One monthly total, typed once, joining the same charts and averages and goals as the automatic sources. Unglamorous. It's the whole product.

Why I built an MCP server instead of a mobile app

Here's the decision I'm actually happy about.

The obvious next step for a dashboard is a mobile app. I didn't build one, because I noticed something about how I use the thing: I never wanted to look at a chart. I wanted to ask a question.

"How much did I make this month across everything?"

That's not a visual query. It's conversational. So instead of an app, I shipped an MCP server. Now I ask Claude and get an answer built from my real numbers:

you ▸ how much did I make this month across everything?
ai  ▸ $412.30 this month (avg $14.22/day). Top: Amazon $109.18,
      Rotate First Officer $98.14, Checkride PDF $47.28.
      You're 94% to your monthly goal.

Four tools: get_income_summary, get_sources, get_month, log_monthly_income. That last one means I can log income by talking, which turns the most tedious part of the whole product into a sentence.

The auth problem nobody warns you about

This is where it got interesting technically.

The hosted app authenticates with Supabase magic links, which produce a JWT that expires in an hour. That's correct for a browser. It's useless for a CLI: an MCP server running under Claude Desktop cannot refresh a browser session.

So for a while my MCP only worked against self-hosted instances, which meant anyone discovering it had to deploy their own Postgres to use it. Not exactly a funnel.

The fix is personal API tokens, and the details are the whole point:

Store a hash, never the token. The plaintext is shown once, at creation. The database keeps a SHA-256 hash. A database leak yields nothing usable.

export function generateToken() {
  const token = 'iok_' + randomBytes(24).toString('hex');
  return { token, hash: hashToken(token), prefix: token.slice(0, 12) };
}

Show a prefix and a last-used timestamp. A credential you can't see is a credential you can't audit. If a token says "never used" six months in, you know to kill it.

A token cannot mint another token. This one I think is underrated:

function isBrowserSession(req: NextRequest): boolean {
  return !(req.headers.get('authorization') || '').includes('iok_');
}

Creating and revoking tokens requires a real browser session. Otherwise one leaked token becomes permanent, self-renewing access — it can quietly issue siblings for itself faster than you can revoke them.

And be honest that a token bypasses 2FA. It does. That's what it is — the machine's replacement for a second factor. GitHub makes the same trade with personal access tokens. The mitigation isn't pretending otherwise, it's making tokens named, scoped to one purpose, individually revocable, and visible.

The mistake that cost me a month

Now the part that's actually useful to you.

I launched the hosted version and it made zero dollars for 26 days. I assumed pricing, or onboarding, or that the market didn't want it.

Then I read my own landing page.

Every call-to-action pointed at the GitHub repo. And near the bottom, still live, in the present tense:

"IncomeOS Cloud **is coming* — join the waitlist and get early access."*

The product had been live and charging for 26 days. My own website was telling every visitor it didn't exist yet, and offering them a waitlist. That waitlist had zero signups, which in hindsight was the only honest metric on the page.

It wasn't a conversion problem. Nobody had ever seen the product.

I have a rule now, and I'd offer it to anyone shipping alone: before you optimise anything, verify a stranger can physically travel from your homepage to your checkout. Click it yourself, in an incognito window, like you've never seen it before. I had built the cash register and forgotten to put a door on the building.

The second lesson from that week: I had zero analytics. No funnel, nothing. Which means every theory I had about why it wasn't converting was a story I told myself. If you're guessing about your funnel, you don't have a hypothesis — you have a feeling.

Where it stands

MIT licensed, self-hostable on Supabase + Vercel in about five minutes. There's a hosted version because I got tired of maintaining my own deploy, and $9/month with a trial felt more honest than a donate button.

Repo: github.com/Perufitlife/incomeos
MCP: npx -y incomeos-mcp

If you also earn from a pile of small places, I'd genuinely like to know how you track it today — especially the sources with no API. That's the part I keep discovering I've underestimated.

Free open-source security auditors for Supabase, Strapi, Hasura, Convex, Ollama & more

Perufitlife — Tue, 23 Jun 2026 01:14:20 +0000

Most backend data leaks aren't clever hacks. They're a database, CMS or API left readable by the anonymous / public role — a default someone forgot to lock down before going to production.

So I built a family of open-source auditors (MIT, zero dependencies) that check for exactly that, and confirm each leak with a read-only anonymous probe — the same request any visitor's browser makes. Nothing is downloaded, nothing is changed. You get the bytes that are actually exposed, not a guess from a config file.

One command each:

npx strapi-security   --url https://your-strapi.example.com
npx directus-security --url https://your-directus.example.com
npx hasura-security   --url https://your-hasura.example.com
npx convex-security   --url https://your-app.convex.cloud
npx ollama-security   --url http://your-host:11434
npx payload-security  --url https://your-payload.example.com
npx n8n-security      --url https://your-n8n.example.com

Plus auditors for Supabase, Firebase, PocketBase, Appwrite and Nhost, and tools for served secret files (.env, .git, source maps) and Claude Code .claude/ config footguns.

Full collection, all MIT:
https://github.com/Perufitlife/awesome-backend-security

Want me to run one for you — free?

If you'd rather not install anything, drop your backend URL and I'll run the matching auditor and post the findings + the exact fixes back to you, free. Read-only, nothing downloaded.

Request a free audit: https://github.com/Perufitlife/awesome-backend-security/issues/new?template=free-audit.yml

If it turns up something and you'd like the fixes done for you, there's a fixed-scope $99 option — but the tools and the audit are free, and that's the point: most of these holes take five minutes to close once you know they're there.

I gave my AI agent live aviation weather — building a free Aviation MCP server

Perufitlife — Sun, 14 Jun 2026 02:26:02 +0000

I'm a commercial pilot who builds software. Last week I noticed something: ask any AI assistant "what's the weather at JFK right now and is it VFR?" and it either guesses, hallucinates a METAR, or tells you to go check a website. LLMs have no live aviation data.

So I built an MCP server that fixes that. It gives Claude, ChatGPT, Cursor — any MCP client — six aviation tools that return real data:

get_metar — current decoded METAR for any ICAO airport (flight category, wind, visibility, temp, dewpoint), optional TAF
get_airport — airport info by ICAO (name, IATA, city, coordinates, elevation, runways)
get_aircraft — aircraft specs by slug (engines, range, cruise, ceiling, MTOW, type rating)
get_glossary_term — definitions from an aviation glossary
practice_questions — FAA-style exam questions with answers
quiz_of_the_day — a daily aviation question

No API key. No signup. It's a thin MCP wrapper over a free aviation API I maintain (Rotate Pilot), so the tools are just typed HTTP calls — the hard part is the data, not the protocol.

Why MCP, and why this was easy

The Model Context Protocol is becoming the default way to hand tools to LLMs in 2026 — Claude, Cursor, Cline, Continue and Windsurf all speak it. If you have any API, wrapping it as an MCP server drops it into every AI client at once. That's a free distribution channel most API owners are sleeping on.

The server runs as an Apify Standby Actor (Streamable HTTP /mcp + legacy SSE), using the official @modelcontextprotocol/sdk. Each tool definition is ~10 lines: a name, a JSON schema, and a buildPath(args) that returns the API path. The server fetches it and returns the JSON. That's the whole thing.

Connect it

{
  "mcpServers": {
    "aviation": {
      "url": "https://renzomacar--aviation-mcp.apify.actor/mcp?token=YOUR_APIFY_TOKEN"
    }
  }
}

Then ask your agent: "Pull the METAR for KSFK and EGLL, tell me which is VFR, and compare a Cessna 172 to a Piper Warrior on cruise speed." It will call the tools and answer from real data.

Try it / source

GitHub (MIT): https://github.com/Perufitlife/aviation-mcp
Apify Store: https://apify.com/renzomacar/aviation-mcp
The underlying free API + OpenAPI spec: https://rotatepilot.com/developers

Curious what other niche data verticals are still missing from the MCP ecosystem — aviation felt like an obvious gap for a pilot. What's yours?

Build a Lead-Gen Automation in n8n: Scrape, Enrich, Export

Perufitlife — Fri, 12 Jun 2026 12:45:42 +0000

Most "lead generation" tutorials stop at scraping a list of business names. But a name and a phone number isn't a lead - a name, a decision-maker email, and a verified contact channel is. In this tutorial we'll build a complete lead-gen pipeline in n8n that does all three stages: scrape businesses from Google Maps, enrich them with emails crawled straight off their websites, and export a clean list to Google Sheets.

No code, no scraper maintenance. We lean on n8n's generic Apify node to run two ready-made actors and chain them together.

The pipeline at a glance

Trigger -> Scrape (Google Maps) -> Enrich (Website Contact Finder) -> Export (Sheets)

Scrape - pull businesses for a niche + city from Google Maps (name, phone, website, rating).
Enrich - take each business website and crawl it for emails, phones, and social links.
Export - write the merged record to Google Sheets as one row per lead.

Stage 1 gives you reach. Stage 2 gives you the email that actually makes the lead actionable.

Prerequisites

A running n8n instance (cloud or self-hosted).
A free Apify account. Grab your Personal API token from Settings -> Integrations.

That's it. Both actors we use are on the Apify Store and run through the same generic Apify node, so you only configure one credential.

Step 1 - Add the Apify credential

Add a node in n8n, search Apify, choose the generic Apify node. When it asks for credentials, select Apify API and paste your token. Save. You'll reuse this credential for both the scrape and enrich steps.

Step 2 - Scrape businesses from Google Maps

Add your first Apify node. Configure it to run the Google Maps Email Extractor actor (renzomacar/google-maps-businesses):

Operation: Run actor and get dataset
Actor: renzomacar/google-maps-businesses
Input (JSON):

{
  "searchQueries": [
    "marketing agencies in Denver CO"
  ],
  "maxResultsPerQuery": 50,
  "language": "en",
  "includeWebsite": false
}

Notice includeWebsite is false here. We deliberately keep this stage fast and cheap - we just want the business list and their website URLs. The deep email crawl happens in the next step with a dedicated tool that does it better.

Each output item looks like:

{
  "name": "Summit Digital",
  "phone": "+1 720-555-0142",
  "website": "https://summitdigital.co",
  "rating": 4.8,
  "reviewsCount": 96
}

Step 3 - Enrich each business with emails

Now the enrichment step. Add a second Apify node, this time running the Email & Contact Finder actor (renzomacar/website-contact-finder). This actor crawls a website's contact, about, and team pages and extracts emails, phone numbers, social profiles, and even the tech stack.

The trick is feeding it the website URLs from Step 2. The actor takes a domains array, so collect the websites from the previous node and pass them in. A simple way: drop a Code node between the two Apify nodes to gather the URLs.

// Code node: collect website URLs from the Google Maps results
const domains = items
  .map(i => i.json.website)
  .filter(Boolean);

return [{ json: { domains } }];

Then configure the second Apify node:

Operation: Run actor and get dataset
Actor: renzomacar/website-contact-finder
Input (JSON):

{
  "domains": {{ $json.domains }},
  "maxPagesPerDomain": 4,
  "includeGenericEmails": true,
  "detectTechStack": true
}

The domains value is mapped from the Code node, so it scales automatically with however many businesses you scraped. Each enriched result comes back like:

{
  "domain": "summitdigital.co",
  "emails": ["hello@summitdigital.co", "jobs@summitdigital.co"],
  "phones": ["+1 720-555-0142"],
  "socialLinks": {
    "linkedin": "https://linkedin.com/company/summit-digital",
    "instagram": "https://instagram.com/summitdigital"
  },
  "techStack": ["WordPress", "HubSpot"]
}

Now you have an email and a social channel for outreach - the difference between a raw list and a usable pipeline. Bonus: the detected tech stack lets you segment ("everyone on HubSpot," "everyone still on WordPress") for sharper messaging.

Step 4 - Merge and export to Google Sheets

You've got two datasets: businesses (Step 2) and contacts (Step 3). Use n8n's Merge node set to Combine -> Merge By Key, keying on the website/domain so each business lines up with its scraped emails. Then add a Google Sheets node with operation Append Row and map the columns:

Sheet column	Expression
Business	`{{ $json.name }}`
Email	`{{ $json.emails[0] }}`
Phone	`{{ $json.phone }}`
Website	`{{ $json.website }}`
LinkedIn	`{{ $json.socialLinks.linkedin }}`
Tech	`{{ $json.techStack.join(", ") }}`

Run it. Each row is now a real, enriched, ready-to-contact lead.

Step 5 - Put it on a schedule

Swap the manual trigger for a Schedule Trigger and rotate your searchQueries across cities and niches. Every run adds fresh, enriched leads to the sheet with no manual effort. Add a dedupe step (key on email or domain) if you run overlapping searches.

Why split scrape and enrich into two actors?

You could ask the Google Maps actor to visit websites itself (includeWebsite: true) and call it a day. That's fine for small jobs. But splitting the stages gives you two wins: the scrape stays fast and cheap, and the enrichment is far more thorough - the contact-finder actor crawls multiple pages per domain (contact, about, team) rather than just the homepage, so it surfaces emails the quick pass misses. For serious outreach lists, the two-stage pipeline pulls noticeably more verified emails.

Wrap-up

That's a full lead-gen machine in n8n with zero scraping code:

Scrape with Google Maps Email Extractor
Enrich with Email & Contact Finder
Export to Sheets, on a schedule

Both actors run through the same generic Apify node, so once your token is in, you can recombine them into any pipeline you like - reviews monitoring, competitor research, recruiting, you name it.

Now go fill that sheet.

How to Scrape Google Maps Leads in n8n Without Code (Emails + Phones)

Perufitlife — Fri, 12 Jun 2026 12:44:28 +0000

Lead generation usually means one of two painful things: paying for an expensive SaaS seat, or hand-copying business names and phone numbers off Google Maps one card at a time. If you already run n8n for your automations, there is a third option that takes about ten minutes to set up and needs zero code.

n8n ships with a generic Apify node. That node can run any actor on the Apify Store and hand you back structured JSON you can pipe into Sheets, a CRM, or an email step. So instead of building a scraper, you point the node at a ready-made one. In this tutorial we will use a Google Maps scraper that pulls business names, phone numbers, websites, ratings, and emails, then drop the results into Google Sheets.

No browser automation to maintain, no proxies to rotate, no captcha headaches. Let's build it.

What you'll build

A 3-node n8n workflow:

Manual / Schedule trigger - kick the run off on demand or nightly
Apify node - run a Google Maps scraper actor with your search terms
Google Sheets node - append every business as a new row

The output is a clean lead list: business name, address, phone, website, rating, review count, and (optionally) the email scraped from the business website.

Step 1 - Get an Apify token

You need a free Apify account. After signing up, go to Settings -> Integrations and copy your Personal API token. The free tier comes with monthly platform credit, which is plenty for testing and small lead lists.

Step 2 - Add the Apify credential in n8n

In n8n, open any workflow and add a new node. Search for Apify and pick the generic Apify node (it talks to the Apify API directly - no custom community node required).

When prompted for credentials, choose Apify API and paste the token from Step 1. Save it. That credential is now reusable across every Apify-powered workflow you build.

Step 3 - Point the node at the Google Maps actor

The Apify node asks for an Actor to run. We'll use the Google Maps Email Extractor actor (renzomacar/google-maps-businesses). It scrapes Google Maps search results and returns structured business data, and it can optionally visit each business website to grab an email - which is exactly what makes it useful for outreach.

In the node:

Operation: Run actor and get dataset
Actor: renzomacar/google-maps-businesses
Input (JSON): paste the config below

{
  "searchQueries": [
    "dentists in Miami FL",
    "coffee shops in Austin TX"
  ],
  "maxResultsPerQuery": 50,
  "language": "en",
  "includeWebsite": true
}

A few notes on these fields:

searchQueries is an array, so you can batch several searches in one run. Use the same phrasing you would type into Google Maps: "<business type> in <city>".
maxResultsPerQuery caps how many businesses per query. Google Maps tops out around 120 per search, so anything up to that is realistic.
includeWebsite: true tells the actor to open each business website and extract emails and social links. This is the magic toggle for outreach - leave it off if you only need phone numbers and want a faster, cheaper run.

Run the node once. You should get an array of business objects back, each looking roughly like this:

{
  "name": "Bright Smile Dental",
  "address": "123 Biscayne Blvd, Miami, FL 33132",
  "phone": "+1 305-555-0199",
  "website": "https://brightsmilemiami.com",
  "email": "hello@brightsmilemiami.com",
  "rating": 4.7,
  "reviewsCount": 214,
  "category": "Dental clinic"
}

Step 4 - Send the leads to Google Sheets

Add a Google Sheets node after the Apify node. Authenticate with your Google account, pick (or create) a spreadsheet, and set the operation to Append Row.

Map the columns to the fields coming out of the Apify node:

Sheet column	n8n expression
Business	`{{ $json.name }}`
Phone	`{{ $json.phone }}`
Email	`{{ $json.email }}`
Website	`{{ $json.website }}`
Rating	`{{ $json.rating }}`
Address	`{{ $json.address }}`

Because the Apify node outputs one item per business, n8n loops automatically - every business becomes its own row. Run the workflow and watch the sheet fill up.

Step 5 (optional) - Email the list to yourself

Want the lead list in your inbox instead? Swap (or add) an email / Gmail node at the end. Pipe the dataset through a small Code or Set node to format it as an HTML table, then send. Now you have a nightly "fresh leads" email with zero manual work.

You can also flip the Apify actor's outputFormat to html-report and it returns a polished, scored lead-list report you can attach directly - handy if you're delivering these to a client.

Make it run on autopilot

Replace the manual trigger with a Schedule Trigger (say, every Monday at 8am) and rotate your searchQueries - different cities, different niches - so each run brings in net-new leads. That's a self-refilling pipeline without writing a single line of scraping code.

Why the node-based approach beats DIY scraping

If you tried to scrape Google Maps yourself inside n8n with an HTTP Request node, you'd immediately hit dynamic JS rendering, rate limits, and layout changes that break your selectors every few weeks. Offloading that to a maintained actor means the brittle part is someone else's problem - you just consume clean JSON. That's the whole point of the Apify node: scraping becomes a single configured step in your automation, not a project.

Wrap-up

In a handful of nodes you've got a no-code lead-gen pipeline: search Google Maps -> extract names, phones, websites and emails -> append to Sheets or email yourself -> schedule it. The same pattern works for any niche and any city.

If you want to go deeper on the contact-enrichment side, the Google Maps Email Extractor actor and its companion contact-finder are both on the Apify Store and run inside n8n exactly the way shown here.

Happy automating.

DEV Community: Perufitlife

How to let Claude schedule your social media posts (MCP, step by step)

Step 1: Add the server

Step 2: Connect the networks you post to

Step 3: Tell Claude your time zone once

Step 4: Schedule one post

Step 5: Or plan the whole week

Step 6: Check and cancel

Videos: the attachment problem

Without Claude: the same thing over REST

When this is the wrong tool

How to post one video to TikTok, Instagram Reels and YouTube Shorts from n8n (works on n8n Cloud)

What you'll build

Before you start

Step 1: Connect the three accounts

Step 2: One credential in n8n

Step 3: The input node

Step 4: Write a caption per network

Step 5: Publish to all three

Step 6: Read the result

Making it safe to run unattended

No public URL?

Limits, honestly

Supabase's Oct 30 grants change: the changelog's rollback reopens every table without RLS

TL;DR

What changes, exactly

What you'll see

What does NOT break

Where it actually bites

The fix that reopens everything

Writing migrations that survive Oct 30

Tables

Sequences: serial vs identity

Views

Functions: the part Oct 30 doesn't touch

Audit what's already exposed

Make local match production now

Catch it in CI

Checklist before October 30

Posting to TikTok from n8n: the App Review wall, and the way around it

Sandbox first — you do not need App Review to get a token

The restriction nobody documents clearly

The chunk rules will bite you at specific file sizes

What the demo video needs to show

If you would rather not do any of this

A user spent a day confirming an email that was already confirmed

The report

The line

Two fixes, and the second is the one that matters

The part I find uncomfortable

What I would take from it

A 100MB video used 460MB of RAM in my serverless function

The symptom

Measuring instead of guessing

The fix: never hold the file

Three details that will bite you

What I would take from this

6 social media API behaviours that are not in the docs

1. TikTok rejects photos, and blames your video

2. privacy_level: "public" is not a thing

3. Access tokens die on very different clocks

4. OAuth state cannot be raw base64

5. Meta needs a Page, not a profile

6. The approvals are the real work

Why I gave my income dashboard an MCP server instead of a mobile app

The problem isn't a missing dashboard

Why I built an MCP server instead of a mobile app

The auth problem nobody warns you about

The mistake that cost me a month

Where it stands

Free open-source security auditors for Supabase, Strapi, Hasura, Convex, Ollama & more

Want me to run one for you — free?

I gave my AI agent live aviation weather — building a free Aviation MCP server

Why MCP, and why this was easy

Connect it

Try it / source

Build a Lead-Gen Automation in n8n: Scrape, Enrich, Export

The pipeline at a glance

Prerequisites

Step 1 - Add the Apify credential

Sequences: `serial` vs `identity`

2. `privacy_level: "public"` is not a thing