- Vrealmatic
- Cloudflare
- Bezpečný deploy
Bezpečný deploy na Cloudflare
API token pro jeden účet, mimo build - krok za krokem, včetně starých chunků po deployi
Návod, podle kterého zvládnete postupovat i bez hlubší znalosti Cloudflare: jak vytvořit token se správnými oprávněními, udržet ho mimo nasazený kód, zamknout deploy na jeden účet, ověřit, že to funguje, a nasadit bez rozbití stránek, které mají návštěvníci otevřené.
Obsah návodu
00 · Přehled
Bezpečný deploy v kostce
Návod nastaví deploy na Cloudflare Workers tak, aby se API token nikdy nedostal do nasazeného kódu, každý deploy šel právě do jednoho účtu a návštěvníkům se po deployi nerozbily otevřené stránky. Je psaný pro Next.js na OpenNext, většina kroků platí pro jakýkoli Worker (Express, Hono, čistý Worker). Každý příkaz jde zkopírovat jedním kliknutím.
Celé nastavení v kostce
- Jeden token na projekt - účtový token jen s oprávněními, která projekt používá, omezený na vaši IP adresu
- Zamčený účet -
"account_id"vewrangler.jsonc, takže deploy nemůže skončit v jiném účtu - Token mimo build - token je v
.env.deploy, který žádný framework nečte; nikdy v.env - Načíst jen pro jeden příkaz - npm skripty soubor načtou ve vlastním bashi;
npm run -s wr --nahrazujenpx wrangler - Ověřit a nasadit - kontrola účtu a výstupu buildu, deploy a zachování starých JS chunků, aby otevřené stránky fungovaly dál
Co potřebujete vyřešit?
| Otázka | Kde najdete odpověď |
|---|---|
| Proč je token v .env nebo wrangler login problém? | Proč → |
| Co potřebuji, než začnu? | Než začnete → |
| Jaká oprávnění má token mít? | Vytvoření tokenu → |
| Jak upravit soubory projektu? | Nastavení projektu → |
| Jak ověřím, že token není v buildu? | Ověření → |
| Po deployi otevřené stránky padají na ChunkLoadError. | Deploy a staré chunky → |
| Token už máme v .env. Co teď? | Přechod ze starého nastavení → |
| Dostávám 403, okno OAuth nebo „not authenticated“. | Řešení problémů → |
Stav k říjnu 2026: Wrangler 4, @opennextjs/cloudflare 1.x, účtové API tokeny. Nastavení běží v produkci na tomto webu (Next.js na OpenNext, D1, R2, Workers Cache). Příkazy potřebují bash: Linux, macOS nebo WSL ve Windows.
01 · Proč
Co je špatně na wrangler login a tokenu v .env
Běžné nastavení, tedy wrangler login nebo token v .env, funguje, ale má dvě slabá místa. Snadno se nasadí do špatného účtu a token se může nepozorovaně dostat do kódu, který běží v produkci.
wrangler login otevře všechny účty
npx wrangler login vás přihlásí přes OAuth jako osobu. Wrangler pak má přístup ke všem účtům, jejichž jste členem: k vlastnímu i ke všem klientským. Stačí jeden příkaz spuštěný ve špatné složce nebo projekt bez pevně daného účtu a deploy, dotaz do D1 nebo smazání bucketu skončí jinde, než má. Token vytvořený pro jeden účet tohle udělat nemůže.
Token v .env skončí v produkci
Wrangler si .env načte sám, takže dát token tam vypadá přirozeně. Jenže frameworky ho čtou také a některé ho zkopírují do buildu:
| Projekt | Jak se token dostane do nasazeného kódu |
|---|---|
| Next.js na OpenNext | build zapíše všechny hodnoty z .env, .env.local, .env.<mode> a .env.<mode>.local do .open-next/cloudflare/next-env.mjs a za běhu je nahraje do process.env |
| Next.js standalone | .next/standalone obsahuje kopii .env |
| Docker / Cloudflare Containers | COPY . . bez .env* v .dockerignore zkopíruje soubor do image |
| Express nebo jiný Worker | dotenv při buildu nebo esbuild define umí hodnoty vložit přímo do bundlu |
| Jakýkoli framework | proměnné s veřejným prefixem (NEXT_PUBLIC_, VITE_) skončí v JavaScriptu, který jde do prohlížeče |
Deploy token uvnitř Workeru znamená, že kdokoli, kdo se dostane k jeho kódu, prostředí nebo logům (chyba, závislost, ladicí endpoint), může nasazovat, číst databáze a mazat úložiště ve vašem účtu. Token platí, dokud ho nesmažete, i když ho mezitím z .env odstraníte.
02 · Než začnete
Co budete potřebovat
Deset minut a těchto pár věcí. Pokud něco chybí, vyřešte to nejdřív, další kroky na tom stojí.
- Projekt s konfigurací Wrangleru:
wrangler.jsonc,wrangler.jsonnebowrangler.tomlv kořeni projektu. - bash: Linux a macOS ho mají. Ve Windows pracujte ve WSL (Ubuntu), na samotné příkazy stačí i Git Bash.
- Přístup do dashboardu Cloudflare cílového účtu s právem vytvářet API tokeny.
- Projekt v gitu, ať přesně vidíte, co se změnilo.
Jaký projekt máte?
| V projektu vidíte | Typ projektu | Co projít |
|---|---|---|
@opennextjs/cloudflare v package.json | Next.js na OpenNext | vše, včetně starých chunků v kapitole 06 |
wrangler.jsonc s "main", bez Next.js | Worker (Express, Hono…) | vše kromě kapitoly 06; použijte kratší skripty |
Dockerfile + containers v konfiguraci | Cloudflare Containers | vše a navíc .env* do .dockerignore |
| Express na vlastním serveru (bez Wrangleru) | není Worker | server žádný token Cloudflare nepotřebuje, držte ho jen na stroji, ze kterého nasazujete |
03 · Token
Vytvořte token pro jeden projekt
Pro každý projekt vytvořte samostatný token. Když budete mít podezření na únik, smažete jeden token a ostatní projekty běží dál. Cloudflare ukáže hodnotu tokenu jen jednou, takže mějte projekt otevřený a připravený token vložit.
Krok 1: Otevřete formulář tokenu ve správném účtu
V dashboardu se přepněte do účtu projektu a otevřete Manage Account → Account API Tokens → Create Token → Custom token. Účtový token patří účtu a do jiného účtu se nikdy nedostane. Funguje i uživatelský token (My Profile → API Tokens), jen ho musíte na jeden účet omezit sami (krok 3).
Krok 2: Pojmenujte token a přidejte jen oprávnění, která projekt používá
Název: např. my-app deploy. Pak pro každý potřebný řádek klikněte na Add more. Podívejte se na bindingy ve svém wrangler.jsonc: d1_databases znamená D1, r2_buckets R2, kv_namespaces KV.
Workers Scripts pokrývá deploy, secrets, Durable Objects i logy. Pokud deploy později spadne na chybějící oprávnění (Queues, Containers, Images), přidejte jen to jedno.
| Oprávnění (typ → položka → úroveň) | Kdy |
|---|---|
| Account → Workers Scripts → Edit | vždy |
| Account → Account Settings → Read | vždy |
| Account → D1 → Edit | d1_databases v konfiguraci |
| Account → Workers R2 Storage → Edit | r2_buckets (i incremental cache OpenNext) |
| Account → Workers KV Storage → Edit | kv_namespaces |
| Zone → Workers Routes → Edit | jen s routes v konfiguraci, a Zone Resources omezte na tu jednu zónu |
Krok 3: Omezte token na jeden účet
Jen ve formuláři uživatelského tokenu: v sekci Account Resources nechte Include a místo All accounts vyberte účet projektu. Je to nejdůležitější pole celého formuláře. Formulář účtového tokenu ho nemá, protože token je k účtu vázaný.
Krok 4: Povolte token jen z vaší IP adresy
V sekci Client IP Address Filtering nechte Allow a zadejte svou veřejnou adresu. Uniklý token je pak jinde k ničemu. Adresy zjistíte takto:
# your public IPv4 address
curl -4 -s https://ifconfig.me; echo
# your public IPv6 address (no output = you have none, skip it)
curl -6 -s --max-time 5 https://ifconfig.me; echoPokud máte i IPv6, přidejte ji přes Add more (adresu nebo její rozsah /64). Jinak se Wrangler může připojit přes IPv6 a dostane chybu 403. Seznam jde upravit i později, třeba když vám poskytovatel adresu změní.
Krok 5: Nastavte platnost, vytvořte token a zkopírujte ho
TTL je nepovinné; rozumná výchozí volba je rok, pak token přegenerujete. Klikněte na Continue to summary → Create Token a hodnotu zkopírujte. Neposílejte ji chatem ani e-mailem, v další kapitole ji vložíte rovnou do projektu. Zkopírujte si i Account ID: na Account home klikněte na tři tečky vedle názvu účtu a zvolte Copy account ID. Account ID není tajné.
04 · Projekt
Nastavení projektu
Pět drobných úprav v projektu. Všechno jsou soubory, které commitujete, kromě .env.deploy, který zůstává jen ve vašem počítači.
Krok 1: Zapište Account ID do wrangler.jsonc
Přidejte "account_id" hned pod "name". Od teď každý deploy i wrangler příkaz tohoto projektu míří jen do tohoto účtu. Pokud má projekt víc konfigurací Wrangleru (např. samostatný statický Worker), přidejte ho do každé.
{
"$schema": "node_modules/wrangler/config-schema.json",
"name": "my-app",
// Locked to one account: a deploy or any wrangler command cannot land in another account.
// The API token lives in .env.deploy (see package.json scripts "deploy" and "wr").
"account_id": "<ACCOUNT_ID>",
// ... the rest of your config stays as it is
}Krok 2: Vložte token do .env.deploy
Vytvořte soubor v kořeni projektu a vložte do něj token. Next.js, OpenNext i Vite načítají jen .env, .env.local, .env.<mode> a .env.<mode>.local, takže se tenhle soubor do buildu nikdy nedostane.
# Only for deploys and the wrangler CLI. Next.js, OpenNext and Vite never read this file.
CLOUDFLARE_API_TOKEN="<API_TOKEN>"# only you can read the file
chmod 600 .env.deploy
# must print a .gitignore rule; if it prints nothing, add one
git check-ignore -v .env.deploy || echo '.env*' >> .gitignore# Docker only: keep all env files out of the image
echo '.env*' >> .dockerignoreKrok 3: Odstraňte proměnné Cloudflare ze všech ostatních env souborů
Smažte řádky CLOUDFLARE_API_TOKEN a CLOUDFLARE_ACCOUNT_ID z .env, .env.local, .env.production a podobných. Účet je teď ve wrangler.jsonc, takže nevzniknou dva zdroje pravdy. První příkaz níže nesmí nic vypsat.
# Which env files still contain Cloudflare variables? (prints names, never values)
grep -l 'CLOUDFLARE_' .env .env.* .dev.vars 2>/dev/null | grep -v '^.env.deploy$'
# Show the variable names in .env without their values
sed 's/=.*/=<redacted>/' .envKrok 4: Nechte token načítat npm skripty
Každý skript spustí vlastní bash, načte do něj .env.deploy a provede jeden příkaz. Token ve vašem terminálu nezůstane a hodnoty z prostředí shellu OpenNext do buildu nezapisuje. V package.json nahraďte odpovídající skripty:
"scripts": {
"dev": "bash -c 'set -a; . ./.env.deploy; set +a; exec next dev'",
"cfbuild": "bash -c 'set -a; . ./.env.deploy; set +a; exec opennextjs-cloudflare build'",
"preview": "bash -c 'set -a; . ./.env.deploy; set +a; opennextjs-cloudflare build && exec opennextjs-cloudflare preview'",
"deploy": "bash -c 'set -a; . ./.env.deploy; set +a; opennextjs-cloudflare build && scripts/keep-old-chunks.sh merge && opennextjs-cloudflare deploy && scripts/keep-old-chunks.sh save'",
"wr": "bash -c 'set -a; . ./.env.deploy; set +a; exec wrangler \"$@\"' wr"
}"scripts": {
"dev": "bash -c 'set -a; . ./.env.deploy; set +a; exec wrangler dev'",
"deploy": "bash -c 'set -a; . ./.env.deploy; set +a; exec wrangler deploy'",
"wr": "bash -c 'set -a; . ./.env.deploy; set +a; exec wrangler \"$@\"' wr"
}dev potřebuje token jen tehdy, když má některý binding "remote": true (pak čte produkční data). Skript scripts/keep-old-chunks.sh, který volá deploy, je v kapitole 06.
Krok 5: Místo npx wrangler používejte npm run -s wr --
Vše za -- dostane Wrangler. Nahraďte npx wrangler i v README, dokumentaci a skriptech, ať nikdo nespustí příkaz bez tokenu.
# instead of: npx wrangler <command>
npm run -s wr -- whoami
npm run -s wr -- tail
npm run -s wr -- d1 execute <DB_NAME> --remote --command "SELECT 1"
npm run -s wr -- r2 object get <BUCKET>/<KEY> --remoteProč ne vlastní --env-file Wrangleru? Funguje jen za názvem příkazu (wrangler whoami --env-file=…), před ním Wrangler vypíše jen nápovědu. Obal je jednodušší a stejný pro všechny příkazy.
Tajemství, která aplikace potřebuje za běhu
API klíče, které serverový kód čte za běhu (platby, e-maily, mapy na serveru), do .env také nepatří. Uložte je jako secrets Workeru. OpenNext je za běhu zkopíruje do process.env, takže se kód nemění. Pozor: secret put vytvoří novou verzi Workeru v produkci.
# Runtime secrets of the app (third-party API keys etc.), never in .env.
# The value is read from .env and piped in, so it never shows up on screen or in the shell history.
grep '^MY_SECRET=' .env | cut -d= -f2- | npm run -s wr -- secret put MY_SECRET
# check (prints names only), then delete the line from .env
npm run -s wr -- secret list05 · Ověření
Kontrola před prvním deployem
Tři kontroly před prvním deployem. Každá trvá pár sekund, a když neprojde, řekne vám přesně, co je špatně.
Krok 1: Wrangler vidí token a správný účet
npm run -s wr -- whoami
# → "You are logged in with an Account API Token" (or "User API Token")
# and the account you expectVidíte jiný účet nebo chybu? Zkontrolujte hodnotu tokenu v .env.deploy a že příkaz spouštíte v kořeni projektu.
Krok 2: Bez obalu Wrangler přihlášený není
npx wrangler whoami
# → "You are not authenticated. Please run `wrangler login`."
# That is correct: without the wrapper there is no token. Do NOT run wrangler login.Pokud hlásí přihlášení, je aktivní stará relace OAuth (spusťte npx wrangler logout) nebo je token pořád v .env či ve vašem shellu (otevřete nový terminál a vraťte se ke kroku 3 kapitoly 04).
Krok 3: Výstup buildu neobsahuje token
Sestavte projekt lokálně (nic se nenasadí) a prohledejte výstup. Obě kontroly vypisují jen názvy, nikdy samotný token.
npm run cfbuild
# OpenNext: no Cloudflare variable in the Worker bundle (must print 0)
grep -c CLOUDFLARE_ .open-next/cloudflare/next-env.mjs
# Any project: no value from .env.deploy anywhere in the build output.
# Prints file names only, never the values. Empty output = OK.
while IFS='=' read -r k v; do v=${v//\"/}; [ -n "$v" ] && [ "${k#\#}" = "$k" ] && \
grep -rlF -- "$v" .open-next .next dist build 2>/dev/null | sed "s|^|$k found in: |"; done < .env.deployNěco nalezeno? Některá proměnná Cloudflare je pořád v .env souboru, který build čte. Odstraňte ji a sestavte znovu.
06 · Deploy
Deploy a zachování starých chunků
Každý build Next.js dá souborům JS a CSS nové názvy. Stránky, které mají návštěvníci otevřené nebo v cache prohlížeče, ale chtějí ty staré. Pokud je nový deploy neobsahuje, stránka se rozbije. Řešení je jednoduché: držet archiv starých chunků a přidávat ho ke každému deployi.
Kdy to bolí
- návštěvník má stránku otevřenou a klikne na odkaz (navigace v prohlížeči načítá další chunky staré verze),
- prohlížeč ukáže HTML z cache (na tomto webu až 10 minut),
- edge nebo CDN cache drží HTML přes deploy (Workers Cache s
cross_version_cache).
Návštěvník vidí prázdnou nebo zamrzlou stránku a konzole hlásí ChunkLoadError nebo 404 pro /_next/static/…. Názvy chunků obsahují hash obsahu, takže se staré a nové soubory nikdy nepřepíšou a je bezpečné držet obojí.
Krok 1: Přidejte skript, který drží staré chunky
Uložte ho jako scripts/keep-old-chunks.sh. merge zkopíruje archivované chunky do čerstvého buildu (nový soubor nikdy nepřepíše), save přidá nasazené chunky do archivu. Archiv leží mimo projekt, v ~/next-deployments-old-assets/<složka projektu>, takže ho čistý checkout ani rm -rf .open-next nesmaže.
#!/usr/bin/env bash
# Keeps the JS/CSS chunks of earlier builds available after a deploy.
# merge before the deploy: copy archived chunks into the fresh build (new files are never overwritten)
# save after a successful deploy: add the deployed chunks to the archive
# Archive: $OLD_ASSETS_DIR, default ~/next-deployments-old-assets/<project folder name>
set -euo pipefail
BUILD=".open-next/assets/_next/static"
ARCHIVE="${OLD_ASSETS_DIR:-$HOME/next-deployments-old-assets/$(basename "$PWD")}/$BUILD"
# Copy files from $1 to $2 that do not exist in $2 yet; the count goes to COPIED.
# Paths keep the leading "./" (build folders may start with "-").
COPIED=0
copy_missing() {
local src=$1 dst=$2 f
COPIED=0
while IFS= read -r -d '' f; do
if [ ! -e "$dst/$f" ]; then
mkdir -p -- "$(dirname -- "$dst/$f")"
cp -p -- "$src/$f" "$dst/$f"
COPIED=$((COPIED + 1))
fi
done < <(cd "$src" && find . -type f -print0)
}
# Delete Windows "Zone.Identifier" files (created when files are copied through Windows Explorer into WSL).
remove_zone_ids() {
local dir n
for dir in "$@"; do
[ -d "$dir" ] || continue
n=$(find "$dir" -type f -name '*:Zone.Identifier' -print -delete | wc -l)
[ "$n" -gt 0 ] && echo "keep-old-chunks: deleted $n Zone.Identifier files in $dir"
done
return 0
}
[ -d "$BUILD" ] || { echo "keep-old-chunks: $BUILD not found, run the build first" >&2; exit 1; }
remove_zone_ids "$ARCHIVE" "$BUILD"
case "${1:-}" in
merge)
if [ -d "$ARCHIVE" ]; then
copy_missing "$ARCHIVE" "$BUILD"
echo "keep-old-chunks: added $COPIED old files from $ARCHIVE"
else
echo "keep-old-chunks: no archive yet ($ARCHIVE), it starts with this deploy"
fi
;;
save)
mkdir -p "$ARCHIVE"
copy_missing "$BUILD" "$ARCHIVE"
echo "keep-old-chunks: archived $COPIED new files to $ARCHIVE"
;;
*)
echo "usage: $0 merge|save" >&2
exit 2
;;
esacchmod +x scripts/keep-old-chunks.shJiné umístění? Nastavte OLD_ASSETS_DIR. Skript z archivu i buildu maže soubory Zone.Identifier z Windows, které vznikají při kopírování přes Průzkumník do WSL.
Krok 2: Nasaďte
Skript deploy z kapitoly 04 už oba kroky volá. Archiv se aktualizuje až po úspěšném deployi, takže se do něj nikdy nedostanou soubory, které nebyly nasazené.
npm run deploy
# 1. build 2. add old chunks 3. deploy 4. archive the deployed chunks
# Step 4 runs only when the deploy succeeded.První deploy vypíše no archive yet, to je v pořádku. Od druhého uvidíte added N old files. Archiv naroste o pár set kilobajtů na deploy. Kdyby byl někdy velký, smažte v něm nejstarší složky buildů (starší než pár týdnů už nikdo nepotřebuje).
Rollback
Statické soubory jsou součástí každé verze Workeru, takže rollback vrátí i soubory té verze. Nový build není potřeba.
npm run -s wr -- deployments list # recent versions
npm run -s wr -- rollback # back to the previous versionDeploy z CI
V GitHub Actions nebo GitLabu uložte token jako tajnou proměnnou (secret) a předejte ho jen krokům, které ho potřebují. Nikdy před buildem negenerujte .env z tajných proměnných CI, tím byste vrátili původní problém. Archiv chunků musí přežít mezi běhy (např. actions/cache). Runnery hostované GitHubem mění IP adresy, takže filtr IP tam nefunguje: použijte samostatný token pro CI s krátkým TTL, nebo vlastní runner s pevnou adresou.
# GitHub Actions: the token goes only to the steps that need it, never into a .env file
- run: npm ci
- run: npx opennextjs-cloudflare build
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }} # only if bindings use "remote": true
- run: scripts/keep-old-chunks.sh merge
env:
OLD_ASSETS_DIR: ${{ runner.temp }}/old-assets # restore it with actions/cache
- run: npx opennextjs-cloudflare deploy
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
- run: scripts/keep-old-chunks.sh save
env:
OLD_ASSETS_DIR: ${{ runner.temp }}/old-assets07 · Přechod
Přechod z tokenu v .env
Pokud byl token dosud v .env, je zabudovaný ve Workeru, který právě teď běží v produkci. Postupujte v tomto pořadí: web poběží dál a starý token přestane platit až ve chvíli, kdy ho už nic nepotřebuje.
- Vytvořte nový token (kapitola 03).
- Upravte projekt:
account_id,.env.deploys novým tokenem, vyčištěný.env, skripty (kapitola 04). - Ověřte účet a build (kapitola 05).
- Nasaďte (
npm run deploy). Worker, který teď běží, už žádný token neobsahuje. - Teprve teď smažte starý token v dashboardu. Až do deploye byl v produkci a platný.
- Zrušte přístup přes OAuth, pokud jste někdy použili
wrangler login:
npx wrangler logout
# then in the dashboard: My Profile → Access Management → Connected Applications → revoke WranglerOvěřte to příkazem git log --all --oneline -- .env. Pokud něco vypíše, token je v historii repozitáře. Chrání vás smazání tokenu v dashboardu (krok 5), přepis historie je volitelný.
08 · Problémy
Když něco nefunguje
Nejčastější potíže a co s nimi, zhruba v pořadí, v jakém je můžete potkat.
| Co vidíte | Příčina | Co udělat |
|---|---|---|
| Okno OAuth: Wrangler wants to access your account | příkaz běží bez tokenu (přímo npx wrangler …) | klikněte na Cancel a spusťte ho znovu přes npm run -s wr -- |
| You are not authenticated | totéž: v prostředí není token | použijte npm skript; wrangler login nespouštějte |
| 403 / Authentication error | změnila se vaše IP adresa, připojujete se přes IPv6 nebo chybí oprávnění | zkontrolujte svou IP (krok 4) a seznam IP u tokenu, pak oprávnění |
.env.deploy: No such file or directory | příkaz neběží v kořeni projektu | cd do složky s package.json |
| Wrangler vypíše jen nápovědu | --env-file před názvem příkazu | použijte obal, nebo dejte přepínač za příkaz |
| Build spadne při čtení D1 / R2 | binding má "remote": true a build běží bez tokenu | sestavujte přes npm run cfbuild, ne přes npx opennextjs-cloudflare build |
ChunkLoadError po deployi | deploy neobsahoval staré chunky | zkontrolujte cestu k archivu ve výpisu deploye (kapitola 06) |
bash: command not found ve Windows | npm spouští skripty v cmd nebo PowerShellu | pracujte ve WSL (Ubuntu), nebo nastavte npm script-shell na Git Bash |
- Jeden projekt = jeden token, jeden účet v account_id a token v .env.deploy.
- Nikdy token Cloudflare v .env a nikdy wrangler login. Okno OAuth znamená, že příkaz běží bez tokenu: Cancel.
- Před prvním deployem zkontrolujte výstup buildu. Po přechodu smažte starý token až ve chvíli, kdy běží nový deploy.
- Staré chunky _next/static držte v archivu mimo projekt a přidávejte je ke každému deployi.
Zdroje
Oficiální dokumentace a další čtení
Návod vychází z dokumentace Cloudflare a OpenNext a z našeho produkčního nastavení:
- Account API tokensÚčtové tokeny a rozdíly oproti uživatelským.
- Vytvoření API tokenuOprávnění, zdroje, filtr IP a TTL.
- Proměnné prostředí WrangleruCLOUDFLARE_API_TOKEN a další proměnné, které Wrangler čte.
- Konfigurace Wrangleruaccount_id, bindingy a vzdálené bindingy.
- SecretsTajné hodnoty Workeru za běhu.
- OpenNext: proměnné prostředíKteré .env soubory OpenNext čte a jak se dostanou do Workeru.
Související
- Cloudflare wikiAPI tokeny, R2 z příkazové řádky, limity plánů.
- Next.js na Cloudflare (anglicky)Statický build, OpenNext Worker, D1, R2 a incremental cache.
- Cloudflare Workers CacheEdge cache před Workerem, purge a deploy.
Jak citovat tuto publikaci (ČSN ISO 690:2022)NEPOR, Vladimír. Bezpečný deploy na Cloudflare přes API token (Wrangler, OpenNext). Online. Vrealmatic, 2026. Dostupné z: https://vrealmatic.com/cs/cloudflare/deploy. [citováno ].
Nasazujete do více účtů Cloudflare?
Nastavíme tokeny, deploy i celý stack Cloudflare tak, aby nic tajného neskončilo v produkčním kódu.