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é.

Vladimír NeporAutorIng. Vladimír Nepor
Publikováno
Bezpečný deploy: API token je v .env.deploy, obal v bashi ho načte jen pro jeden příkaz a wrangler.jsonc zamkne deploy na jeden účet Cloudflare. Build token nikdy nevidí..env.deployCLOUDFLARE_API_TOKEN=•••••••token tohoto projektuchmod 600 · .gitignore✕ build ho nikdy nečtenpm run deploybash -c 'set -a; . …'exec wrangler deploytoken jen protento jeden příkazCloudflare"account_id": "a1b2…"jen jeden účetwrangler.jsonc03 · TOKENToken pro jeden účetminimum oprávnění + filtr IPkapitola →04 · PROJEKTToken mimo buildaccount_id + .env.deploy + skriptykapitola →05 · OVĚŘENÍKontrola před deployemwhoami + kontrola buildukapitola →06 · DEPLOYDeploy bez rozbitých stránekzachování starých chunkůkapitola →
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

  1. Jeden token na projekt - účtový token jen s oprávněními, která projekt používá, omezený na vaši IP adresu
  2. Zamčený účet - "account_id" ve wrangler.jsonc, takže deploy nemůže skončit v jiném účtu
  3. Token mimo build - token je v .env.deploy, který žádný framework nečte; nikdy v .env
  4. Načíst jen pro jeden příkaz - npm skripty soubor načtou ve vlastním bashi; npm run -s wr -- nahrazuje npx wrangler
  5. 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ázkaKde 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ů →
Rozsah

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:

Nahoře: token v .env načte build OpenNext, zapíše ho do next-env.mjs a skončí v produkčním Workeru. Dole: token v .env.deploy načte jen obal pro wrangler CLI, build ho nečte a Worker žádný token neobsahuje.✕ Token v .env.envCLOUDFLARE_API_TOKEN=…Build OpenNextčte všechny .env*Produkční Workertoken v process.env✓ Token v .env.deploy.env.deployCLOUDFLARE_API_TOKEN=…Obal v bashijen pro wranglerCloudflare APIdeploy do jednoho účtuBuild čte jen .env, .env.local, .env.<mode>: ve Workeru žádný token není
Stejný token, dva soubory. Jen spodní cesta ho udrží mimo nasazený Worker.
ProjektJak se token dostane do nasazeného kódu
Next.js na OpenNextbuild 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 ContainersCOPY . . bez .env* v .dockerignore zkopíruje soubor do image
Express nebo jiný Workerdotenv při buildu nebo esbuild define umí hodnoty vložit přímo do bundlu
Jakýkoli frameworkproměnné s veřejným prefixem (NEXT_PUBLIC_, VITE_) skončí v JavaScriptu, který jde do prohlížeče
Proč na tom záleží

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.json nebo wrangler.toml v 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íteTyp projektuCo projít
@opennextjs/cloudflare v package.jsonNext.js na OpenNextvše, včetně starých chunků v kapitole 06
wrangler.jsonc s "main", bez Next.jsWorker (Express, Hono…)vše kromě kapitoly 06; použijte kratší skripty
Dockerfile + containers v konfiguraciCloudflare Containersvše a navíc .env* do .dockerignore
Express na vlastním serveru (bez Wrangleru)není Workerserver žá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 → Editvždy
Account → Account Settings → Readvždy
Account → D1 → Editd1_databases v konfiguraci
Account → Workers R2 Storage → Editr2_buckets (i incremental cache OpenNext)
Account → Workers KV Storage → Editkv_namespaces
Zone → Workers Routes → Editjen 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:

Terminál
# 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; echo

Pokud 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é.

wrangler.jsonc
{
  "$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.

.env.deploy
# Only for deploys and the wrangler CLI. Next.js, OpenNext and Vite never read this file.
CLOUDFLARE_API_TOKEN="<API_TOKEN>"
Terminál
# 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
Terminál
# Docker only: keep all env files out of the image
echo '.env*' >> .dockerignore

Krok 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.

Terminál
# 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>/' .env

Krok 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:

package.json (Next.js na OpenNext)
"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"
}
package.json (ostatní Workery)
"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.

Terminál
# 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> --remote

Proč 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.

Terminál
# 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 list

05 · 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

Terminál
npm run -s wr -- whoami
# → "You are logged in with an Account API Token" (or "User API Token")
#   and the account you expect

Vidí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í

Terminál
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.

Terminál
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.deploy

Ně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.

Stránka otevřená před deployem (verze 1) chce svůj chunk a1.js. Po prostém deployi verze 2 soubor chybí: 404 a ChunkLoadError. Se sloučeným archivem obsahuje verze 2 i staré chunky a stránka funguje dál.Otevřený panelstránka načtená z v1GET a1.jsDeploy v2 bez archivua2.jsb2.jsa1.js✕ 404 → ChunkLoadErrorDeploy v2 + chunky z archivua2.jsb2.jsa1.jsb1.jsz archivu ↓✓ 200 → stránka funguje
Panel otevřený před deployem chce své chunky. Má je jen deploy s archivem.

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.

scripts/keep-old-chunks.sh
#!/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
    ;;
esac
Terminál
chmod +x scripts/keep-old-chunks.sh

Jiné 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é.

Terminál
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.

Terminál
npm run -s wr -- deployments list   # recent versions
npm run -s wr -- rollback           # back to the previous version

Deploy 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/workflows/deploy.yml (kroky)
# 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-assets

07 · 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.

  1. Vytvořte nový token (kapitola 03).
  2. Upravte projekt: account_id, .env.deploy s novým tokenem, vyčištěný .env, skripty (kapitola 04).
  3. Ověřte účet a build (kapitola 05).
  4. Nasaďte (npm run deploy). Worker, který teď běží, už žádný token neobsahuje.
  5. Teprve teď smažte starý token v dashboardu. Až do deploye byl v produkci a platný.
  6. Zrušte přístup přes OAuth, pokud jste někdy použili wrangler login:
Terminál
npx wrangler logout
# then in the dashboard: My Profile → Access Management → Connected Applications → revoke Wrangler
Byl token někdy v gitu?

Ověř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ítePříčinaCo udělat
Okno OAuth: Wrangler wants to access your accountpří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 authenticatedtotéž: v prostředí není tokenpoužijte npm skript; wrangler login nespouštějte
403 / Authentication errorzmě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 directorypříkaz neběží v kořeni projektucd do složky s package.json
Wrangler vypíše jen nápovědu--env-file před názvem příkazupoužijte obal, nebo dejte přepínač za příkaz
Build spadne při čtení D1 / R2binding má "remote": true a build běží bez tokenusestavujte přes npm run cfbuild, ne přes npx opennextjs-cloudflare build
ChunkLoadError po deployideploy neobsahoval staré chunkyzkontrolujte cestu k archivu ve výpisu deploye (kapitola 06)
bash: command not found ve Windowsnpm spouští skripty v cmd nebo PowerShellupracujte ve WSL (Ubuntu), nebo nastavte npm script-shell na Git Bash
Shrnutí
  • 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í

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.

Rezervovat schůzku