Att driva en Cloudflare Workers-app i produktion utan löpande kostnader

I vårt förra inlägg gick vi igenom arkitekturen bakom Shrtnr: varför vi valde Cloudflare Workers, varför D1 är källan till sanning, och hur KV ligger framför som en write-through-cache för den heta sökvägen för omdirigeringar. Det här inlägget tar vid där det slutade och tittar på produktionssidan: autentisering, deployment, operativ komplexitet, SDK:erna och vad det faktiskt kostar.

Det som spelar roll för de flesta team är om grejen fungerar i produktion utan att någon behöver passa den. Så här ser det ut.

Tre autentiseringssystem, en Worker

Olika konsumenter behöver olika åtkomstmönster. En teammedlem som öppnar adminpanelen är inte samma sak som en CI-pipeline som skapar länkar, vilket inte är samma sak som en AI-assistent som hämtar analys. Shrtnr hanterar alla tre från en enda deployment.

Adminpanelen använder Cloudflare Access. JWT-verifiering mot din Access-applikation. Teammedlemmar autentiserar sig genom din befintliga identitetsleverantör, oavsett om det är Google Workspace, Okta, Azure AD eller något annat du redan har satt upp. Ingen egen autentiseringskod att underhålla, inga lösenordsåterställningsflöden att bygga.

Det publika API:et använder bearer token-autentisering med scope-baserade API-nycklar. Varje nyckel bär explicita scopes (läs, skapa) så att du kan utfärda en läsbehörig nyckel för en dashboard-integration och en skrivbehörig nyckel för din deployment-pipeline. Nycklar hashas innan lagring. Standardpraxis, men värt att nämna.

MCP-endpointen (för AI-assistentåtkomst, beskriven i detalj i en framtida artikel) använder OAuth 2.0 via Cloudflare Access Managed OAuth. Full protokoll-efterlevnad, tokenutfärdande, identitetsverifiering. AI-agenten autentiserar sig på samma sätt som en människa skulle, med ägarskapskontroller som tillämpas per operation.

Alla tre körs i samma Worker. Ingen separat autentiseringstjänst. Ingen gateway-proxy. En kodbas. Det är inte oavsiktlig komplexitet, det är den minsta livskraftiga säkerhetsmodellen för ett verktyg som betjänar människor, skript och AI-agenter samtidigt.

Deployment med ett klick, inget att underhålla

Arkitekturen och kostnadsbesparingarna är verkliga, men det som betyder något långsiktigt är vad du slutar tänka på.

Det finns ingen skalningskonfiguration. Ingen regional deploymentstrategi. Ingen lastbalanserare att trimma. Ingen failover-uppsättning. Ingen container-orkestrering. Inga "det fungerar i staging men time-out:ar i produktion"-felsökningssessioner kl. 02. Workern körs överallt som standard, och Cloudflare hanterar resten. Det är en hel klass av operativa problem som inte existerar.

Cloudflare tillhandahåller en deploy-knapp som forkar repot och provisionerar Workern och D1-databasen i ett enda steg. Du klickar på den, auktoriserar ditt Cloudflare-konto, och stacken levereras.

För team som vill ha kontinuerlig deployment innehåller repot ett GitHub Actions-arbetsflöde som hanterar databasmigreringar automatiskt när kod landar på main. Arbetsflödet löser upp D1-databasens UUID från Cloudflare-API:et och tillämpar väntande migreringar med wrangler d1 migrations apply. Pusha till main, migreringar körs, Workern omdistribueras. Inga deploy-skript att sköta.

Hela deployment-konfigurationen finns i wrangler.jsonc. Worker-bindningar, D1-databas, KV-namespace, Durable Objects, observability-inställningar. Tracing, invokationsloggning och uppladdning av source maps är aktiverade som standard. Observability i produktionsklass utan en separat övervakningsstack.

Vad det kostar

Shrtnr körs helt och hållet inom Cloudflares gratistier för de flesta arbetsbelastningar.

Workers ger dig 100 000 förfrågningar per dag. Det täcker omdirigeringar, API-anrop, sidladdningar för admin och eventuella verktygsanrop. D1 ger dig 5 GB lagring, 5 miljoner radläsningar per dag och 100 000 radskrivningar per dag. KV är inkluderat med generösa gränser i gratisnivån, och Durable Objects ingår tillsammans med Workers.

Som referens: 100 000 dagliga förfrågningar räcker för ett företag som gör flera miljoner klick på korta länkar per månad, beroende på hur trafiken sprids över dagen. De flesta team kommer aldrig att behöva gå förbi gratisnivån. Om du gör det startar Cloudflares betalplan på 5 USD/månad och skalar linjärt. Jämför det med kommersiella förkortare som tar mellan 25 och flera hundra dollar i månaden för infrastruktur du inte kontrollerar och inte kan granska.

SDK:er för varje stack

Shrtnr levereras med native-SDK:er för TypeScript, Dart/Flutter och Python, alla som omsluter samma publika REST-API. Välj den som matchar din runtime:

• TypeScript / Node / Deno / Bun / Browser: @oddbit/shrtnr på npm
• Dart / Flutter / iOS / Android: shrtnr på pub.dev
• Python 3.11+: shrtnr på PyPI

Varje SDK täcker hela API-ytan: link-CRUD, slug-hantering, bundles, analysfrågor och hälsokontroller. Formen är densamma över alla tre, så ett arbetsflöde du bygger i en stack porteras rent till en annan. Vi lägger till nya SDK:er när vårt eget arbete och våra kunders arbete kräver det, så listan kommer att växa.

Så här ser det ut att skapa en länk i TypeScript:

import { ShrtnrClient } from "@oddbit/shrtnr";

const client = new ShrtnrClient({
  baseUrl: "https://your-domain.com",
  auth: { apiKey: "sk_your_api_key" },
});

const link = await client.createLink({
  url: "https://example.com/campaign",
  label: "Q2 launch",
});

const analytics = await client.getLinkAnalytics(link.id);

Dart- och Python-klienterna följer samma konstruktor- och metodnamn. Om ditt team levererar en mobilapp, en Python-datapipeline och en TypeScript-backend ser Shrtnr-integrationen likadan ut på alla tre ställena.

Öppen källkod, Apache 2.0

Hela kodbasen finns på GitHub. Apache 2.0-licens. Forka den, modifiera den, kör den på ditt eget Cloudflare-konto. Varje migrering, varje analysfråga, varje autentiseringsflöde är synligt och granskbart.

Vi underhåller Shrtnr eftersom vi använder det dagligen. Vår korta domän oddb.it körs på det i produktion. Buggfixar och funktioner landar för att vi själva stöter på kanterna, inte för att en roadmap-kommitté bestämde att de var viktiga.

Vad vi har lärt oss av att köra Workers i produktion

Om du överväger Cloudflare Workers för en produktionsbelastning, är det här vad vi har tagit med oss från Shrtnr och från att bygga Workers-baserade system för kunder:

D1 är produktionsredo för läsintensiva arbetsbelastningar. Analysfrågorna i Shrtnr körs tusentals gånger om dagen utan problem. Skrivprestandan är bra för händelseregistrering i måttlig skala. För hög skrivgenomströmning vill du titta på buffringsstrategier eller Queues.

Hono är ramverket att välja. Vi har provat flera tillvägagångssätt på Workers, och Hono ger konsekvent den bästa utvecklarupplevelsen med minst runtime-överraskningar. TypeScript-stödet är starkt, och edge-native JSX-rendering eliminerar en hel kategori av frontend-komplexitet.

Autentisering är enklare än du tror. Cloudflare Access hanterar identitetsfederation, och att lägga API-nyckelautentisering ovanpå är okomplicerat. Du behöver inte en separat autentiseringstjänst för de flesta produkter.

Gratisnivån är på riktigt. Vi har kört produktionstrafik genom den i flera månader. Det fungerar. Gränserna är rimliga och uppgraderingsvägen är mjuk. Den större vinsten är den operativa kostnaden: det finns inga servrar att patcha, inga containrar att rätt-dimensionera, inget CDN att konfigurera separat. Det är där de verkliga besparingarna ackumuleras.

Vad händer härnäst

Nästa inlägg i den här serien handlar om biten som gör Shrtnr AI-native som standard: MCP-servern som låter AI-assistenter skapa länkar, hämta analys och hantera hela din länkinfrastruktur utan att en människa öppnar en webbläsare. Om ditt team utforskar AI-native arbetsflöden eller MCP-integration är det den att hålla utkik efter.

Om Oddbit

Vi är ett senior mjukvaruutvecklingsteam baserat på Bali, Indonesien, med rötter i Sverige. Vi bygger skräddarsydd programvara för startups och scale-ups: webbapplikationer, mobilappar, SaaS-plattformar och integrationerna som kopplar ihop dem. Våra kunder spänner över Norden, Europa och Sydostasien, och vi har gjort det här i 9 år över 50+ projekt.

Shrtnr är ett av flera öppen källkod-verktyg vi har byggt och släppt. Andra inkluderar Tanam (ett Firebase-CMS med AI-innehållsgenerering), Flutter-paket med tiotusentals nedladdningar på pub.dev, och Firebase Genkit-plugins för AI-modellintegration.

Om du arbetar med ett tekniskt arkitekturbeslut, utvärderar edge computing för din produkt eller bygger något från grunden, prata med oss. Vi visar hellre vårt arbete än berättar om det.