PDFCraft
Supabase Edge Functions

PDF generation in Supabase Edge Functions

Deno runtime, so the fetch is standard — but the natural next step is writing the PDF into Supabase Storage and handing back a signed URL, which is a different shape from returning bytes.

The code

import { createClient } from 'jsr:@supabase/supabase-js@2';

Deno.serve(async (req) => {
  const { html, path } = await req.json();

  const upstream = await fetch('https://api.pdfcraft.dev/v1/render', {
    method: 'POST',
    headers: {
      authorization: `Bearer ${Deno.env.get('PDFCRAFT_API_KEY')}`,
      'content-type': 'application/json',
    },
    body: JSON.stringify({ html, options: { printBackground: true } }),
  });

  if (!upstream.ok) {
    return new Response(await upstream.text(), { status: upstream.status });
  }

  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
  );

  await supabase.storage
    .from('documents')
    .upload(path, await upstream.arrayBuffer(), { contentType: 'application/pdf', upsert: true });

  const { data } = await supabase.storage.from('documents').createSignedUrl(path, 3600);
  return Response.json({ url: data?.signedUrl });
});

What to watch for

Why not run the browser yourself

You can. Puppeteer and Playwright both work, and for a script you run by hand they are the right answer. The cost arrives at the point it becomes a service someone depends on: one long-lived browser per process rather than one per request, a semaphore so four renders do not become forty, a hard timeout that force-closes a hung page before it holds a slot forever, a scheduled restart because Chromium leaks, and a Chromium version you are now responsible for patching.

None of that is hard. All of it is work that has nothing to do with your product, and it fails under concurrency rather than in testing — which is the worst time to discover it.

Other frameworks

Or by language