Rychlé nasazení SSR aplikace na AWS

SSR aplikace na AWS nasadíte nejrychleji, když nebudujete vlastní platformu. V článku projdeme praktickou volbu mezi App Runnerem, Amplify Hostingem, Fargate a Lambdou, ukážeme Docker build pro Next.js a upozorníme na místa, kde se rychlý deploy nejčastěji rozbije.

Nejrychlejší produkční cesta přes App Runner

Pro obecnou SSR aplikaci na AWS je nejkratší rozumná cesta kontejner. Aplikaci zabalíte do Docker image, uložíte do Amazon ECR a spustíte jako službu v AWS App Runner. Dostanete HTTPS endpoint, škálování, logy a health check bez ruční konfigurace clusteru.

App Runner je dobrý kompromis mezi „chci to dnes spustit“ a „nechci se za měsíc stydět za architekturu“. Oficiální popis služby najdete v dokumentaci AWS App Runner. Pro Node.js SSR je podstatné, že nasazujete běžící HTTP server, ne statický export.

Největší úspora času je v tom, co neděláte. Nezakládáte vlastní ECS cluster, nepíšete target group, neřešíte ALB listener a nelepíte TLS certifikát ručně. U malého až středního produktu tím často ušetříte půl dne až několik dnů infrastruktury.

Cena za tuto jednoduchost je menší kontrola nad síťovou a provozní vrstvou. Pokud potřebujete detailně ladit load balancer, sidecary, servisní mesh nebo komplikované privátní routování, App Runner už nemusí stačit. Pro první produkční verzi SSR aplikace ale bývá správně pragmatický.

Kdy vybrat Amplify, Fargate nebo Lambda

AWS má pro webový runtime několik cest. Rychlost nasazení není jen počet kliknutí v konzoli, ale také počet rozhodnutí, která musíte udělat správně. U SSR hostingu rozhoduje framework, provozní režim, týmová zkušenost a očekávaný růst aplikace.

Doporučujeme volit podle toho, jak moc se chcete odchýlit od výchozího chování frameworku. Čím víc vlastních runtime požadavků, tím víc se vyplatí kontejner. Čím čistší frameworkový projekt, tím víc dává smysl managed hosting typu Amplify.

Amplify Hosting pro frameworkově čistý Next.js

AWS Amplify Hosting je pravděpodobně nejrychlejší cesta, pokud máte standardní Next.js projekt, Git repozitář a nechcete psát Dockerfile. Připojíte repozitář, nastavíte build příkaz, proměnné prostředí a necháte AWS řešit runtime pro podporovaný framework.

Pro Next.js SSR je vhodné nejdřív ověřit podporované scénáře v dokumentaci AWS Amplify pro Next.js. Pokud aplikace používá nestandardní server, vlastní binárky nebo složitější monorepo build, Amplify může začít brzdit právě tam, kde App Runner zůstává přímočarý.

ECS Fargate, když potřebujete síť a kontrolu

ECS Fargate je robustnější varianta pro týmy, které už mají AWS infrastrukturu pod kontrolou. Dává smysl, když potřebujete privátní subnety, více služeb, vlastní load balancer, přesnější autoscaling nebo napojení na existující VPC pravidla.

Nevýhoda je rychlost prvního deploye. Musíte rozhodnout cluster, task definition, service, target group, security groups, IAM role a logování. U dlouhodobě provozované platformy je to v pořádku. U jedné SSR aplikace na AWS je to často zbytečný náběhový odpor.

Lambda varianta pro nepravidelný provoz

Serverless přístup přes Lambda a nástroje typu OpenNext může být vhodný pro nepravidelný provoz, menší API a projekty citlivé na platbu za nečinnost. Není to ale nejrychlejší obecná odpověď, pokud chcete prostě spustit Node.js SSR server.

Lambda architektura rozkládá aplikaci na funkce, cache, CDN a další AWS komponenty. To je silné, ale přidává povrch pro ladění. Pokud tým nemá serverless zkušenost, bude první produkční incident dražší než pár ušetřených dolarů za běžící kontejner.

Příprava SSR runtime před deployem

Než řešíte AWS, zkontrolujte runtime kontrakt aplikace. Server musí poslouchat na portu z proměnné PORT, nesmí vyžadovat lokální zápis do perzistentního souborového systému a build nesmí záviset na tajných hodnotách, které patří až do runtime.

Typický problém u SSR je záměna build-time a runtime konfigurace. Veřejné hodnoty pro klienta patří do build procesu, tajné tokeny zůstávají na serveru. Pokud se API endpoint nebo OAuth secret propíše do image, rollback i audit začínají bolet.

U Next.js doporučujeme pro kontejnerový deploy používat standalone output. Minimalizuje velikost runtime artefaktu a kopíruje jen soubory potřebné pro běh serveru. Detaily chování popisuje dokumentace Next.js standalone output.

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  output: 'standalone',
}

export default nextConfig

Stejný princip platí i pro jiné SSR frameworky. Potřebujete jasný build artefakt a jeden start příkaz. Jestli aplikace vyžaduje ruční kroky po buildu, nejdřív je přesuňte do skriptů. Ruční postup se v produkci vždycky vrátí jako chyba v release procesu.

Dockerfile pro Next.js standalone build

Dockerfile má být nudný. V produkci nechcete kreativní shell skript, který funguje jen na notebooku jednoho vývojáře. Potřebujete vícefázový build, zamčené závislosti, minimální runtime image a start přes Node server generovaný frameworkem.

Ukázka níže počítá s Next.js standalone výstupem. Používá npm ci, kopíruje statické soubory a spouští server na portu 3000. App Runner umí port namapovat podle konfigurace služby, ale aplikace musí opravdu poslouchat tam, kde tvrdíte.

FROM node:22-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci

FROM node:22-alpine AS builder
WORKDIR /app
ENV NEXT_TELEMETRY_DISABLED=1
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
ENV PORT=3000

RUN addgroup -S nodejs && adduser -S nextjs -G nodejs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]

Všimněte si, že image neobsahuje .env soubor. To je záměr. Konfigurace patří do prostředí služby nebo do secret storage, ne do kontejneru. Jeden image pak můžete bezpečně pustit ve stagingu i v produkci s jinými proměnnými.

Pokud používáte pnpm nebo Bun, princip zůstává stejný. Zamknout verzi package manageru, instalovat deterministicky, buildovat v oddělené vrstvě a do runtime kopírovat jen výsledek. U SSR aplikace na AWS řešte menší image až po tom, co máte opakovatelný deploy.

Push image do ECR a vytvoření služby

Další krok je Amazon ECR. Repository vytvoříte jednou, potom do něj posíláte verze image z lokálu nebo CI. Pro produkci preferujeme tag podle commitu, ne jen latest. Jinak nevíte, co přesně běží a co rollback vrací zpět.

Následující příkazy ukazují minimální tok přes AWS CLI. Hodnoty AWS_ACCOUNT_ID, AWS_REGION a název repository si nastavte podle účtu. Pro Apple Silicon buildy je důležitý parametr platformy, aby image seděl na linuxový runtime.

export AWS_REGION=eu-central-1
export AWS_ACCOUNT_ID=123456789012
export REPOSITORY=next-ssr-app
export IMAGE_TAG=$(git rev-parse --short HEAD)

aws ecr create-repository \
  --repository-name $REPOSITORY \
  --region $AWS_REGION || true

aws ecr get-login-password --region $AWS_REGION | \
  docker login --username AWS --password-stdin \
  $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com

docker buildx build \
  --platform linux/amd64 \
  -t $REPOSITORY:$IMAGE_TAG \
  --load .

docker tag $REPOSITORY:$IMAGE_TAG \
  $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPOSITORY:$IMAGE_TAG

docker push \
  $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/$REPOSITORY:$IMAGE_TAG

Službu v App Runneru můžete vytvořit z konzole rychleji než psát první IAM JSON ručně. Vyberete ECR image, port 3000, automatické nebo manuální deploymenty a nastavíte health check. Jakmile postup stabilizujete, přesuňte konfiguraci do Terraformu nebo AWS CDK.

Pro týmy, které u nás řeší vývoj webových aplikací, obvykle začínáme přes managed službu a infrastrukturu zpřesňujeme až podle provozu. Je to rychlejší než navrhnout ideální AWS topologii před tím, než aplikace dostane první reálné uživatele.

Konfigurace proměnných, secretů a domény

Rychlý deploy nesmí znamenat chaotickou konfiguraci. Rozdělte proměnné na veřejné, serverové a citlivé. Veřejné hodnoty s prefixem frameworku mohou být součástí klientského bundlu. Databázové URI, API klíče a podpisové secrety tam nikdy nepatří.

V App Runneru nastavíte environment variables přímo u služby, případně napojíte hodnoty ze secrets. Pro první verzi stačí konzole, ale u produkce doporučujeme mít seznam proměnných v repozitáři jako šablonu bez hodnot. Reviewer pak vidí, co aplikace očekává.

# .env.example bez tajných hodnot
NODE_ENV=production
PORT=3000
APP_BASE_URL=https://example.com
DATABASE_URL=
SESSION_SECRET=
API_TOKEN=

Doménu připojte až po ověření, že health check prochází a aplikace vrací korektní odpovědi. DNS změna se špatně ladí, když zároveň nevíte, jestli padá kontejner, route handler nebo TLS. Nejdřív testujte na výchozí App Runner URL.

U cookies zkontrolujte Secure, SameSite a doménu. SSR aplikace za proxy často potřebuje správně číst hlavičky X-Forwarded-Proto a Host. Bez toho se přihlášení tváří náhodně rozbité, hlavně mezi stagingem a produkcí.

Databáze, migrace a práce se stavem

Kontejner v managed službě berte jako dočasný výpočet, ne jako místo pro stav. Uploady patří do S3 nebo jiné objektové storage, session do podepsané cookie nebo externího úložiště, fronty do samostatné služby. Lokální disk je jen pracovní prostor.

Databázi volte podle aplikace, ne podle AWS katalogu. Pro relační data je běžná volba PostgreSQL v RDS nebo Aurora. Pro MongoDB lze použít Atlas mimo AWS správu. Důležité je síťové napojení, latence v regionu a jasný plán záloh.

Migrace nespouštějte automaticky při startu serveru, pokud se může rozběhnout více instancí. Start aplikace má být rychlý a opakovatelný. Migrační krok spusťte v CI/CD, jednorázovým jobem nebo řízeně před přepnutím nové verze.

U ORM nástrojů typu Prisma, Drizzle nebo TypeORM si ověřte, že build nevyžaduje živé připojení k produkční databázi. Generování klienta patří do buildu, destruktivní změny schématu ne. Tady se rychlé nasazení nejčastěji mění v neplánovaný výpadek.

Observabilita, rollback a bezpečné releasy

Bez logů není rychlý deploy, jen rychlý hazard. Hned od první verze nastavte strukturované serverové logy, request ID a jasné chybové zprávy bez citlivých dat. App Runner posílá logy do CloudWatch, což pro první úroveň diagnostiky stačí.

Health check nemá testovat jen to, že proces žije. Vraťte jednoduchou odpověď z endpointu, který ověří základní připravenost aplikace, ale neshazuje službu kvůli dočasně pomalé závislosti. Příliš přísný health check umí vytvořit výpadek sám o sobě.

// app/api/health/route.ts
import { NextResponse } from 'next/server'

export async function GET() {
  return NextResponse.json({ ok: true }, { status: 200 })
}

Rollback musí být jednoduchý: znovu nasadit předchozí image tag a mít kompatibilní databázové schéma. Proto nepoužívejte pouze latest. Commit SHA nebo release tag je levná pojistka, která při incidentu šetří minuty i nervy.

U produkčního provozu přidejte alert na chybovost, latenci a počet restartů. Nemusí jít hned o složitý APM stack. Důležité je, aby se tým dozvěděl o problému dřív než zákazník a aby logy obsahovaly korelační stopu napříč požadavkem.

CI/CD pipeline místo ručního klikání

Ruční deploy přes konzoli je v pořádku pro první ověření architektury. Neměl by ale zůstat jako produkční proces. Jakmile víte, že SSR aplikace na AWS běží, přesuňte build, testy, push image a update služby do CI/CD pipeline.

Minimální pipeline má čtyři kroky: instalace závislostí, test a lint, build Docker image, push do ECR. Aktualizaci App Runner služby můžete spustit automaticky podle nového image tagu nebo explicitně přes AWS CLI. Explicitní release je pomalejší, ale lépe auditovatelný.

name: deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test -- --runInBand
      - run: npm run build
      # Následuje přihlášení do AWS, docker build, tag a push do ECR.

Do CI nikdy nedávejte dlouhodobé statické AWS klíče, pokud se tomu můžete vyhnout. Lepší je OIDC napojení mezi GitHub Actions a AWS IAM rolí. Pro rychlý prototyp se statické klíče občas objeví, ale patří k dluhu, který má krátkou splatnost.

Pipeline držte blízko aplikace. Pokud je infrastruktura v Terraformu nebo CDK, oddělte změny platformy od běžného releasu image. Aplikační release má být častý a nudný, infrastrukturní změna kontrolovaná a recenzovaná pomaleji.

Co si odnést při hostingu SSR na AWS

Pokud je cílem nejrychleji nasadit SSR aplikaci na AWS a nemáte zvláštní síťové požadavky, začněte App Runnerem. Pro čistý Next.js bez Dockeru zvažte Amplify. ECS Fargate berte jako krok k větší kontrole, ne jako povinný start.

Technicky rozhoduje hlavně příprava aplikace: jasný start příkaz, správný port, oddělené secrety, žádný stav v kontejneru, verzované image a funkční rollback. Když tyto věci sedí, AWS část je relativně mechanická.

Největší chyba je stavět ideální cloudovou platformu před prvním releasem. Nasadit, změřit provoz a teprve potom přidávat složitost je u SSR aplikací zdravější postup. Rychlost má hodnotu jen tehdy, když po ní zůstane opakovatelný a bezpečný deploy.