Lovable x Google Cloud: wat dit betekent voor jouw Claude Code project

Lovable gaat all-in op Google Cloud, en jij?

Lovable, het platform waarmee je zonder code een SaaS bouwt, heeft een meerjarige deal getekend met Google Cloud voor een 5x uitbreiding van z'n infrastructuur. Daarin zit ook bredere toegang tot Anthropic Claude. Kortom: het no-code SaaS-segment schaalt serieus op, met Claude als motor eronder.

Dat zegt iets over de richting van de markt. Maar als jij al bouwt met Claude Code, hoef je niet te wachten op Lovable's roadmap. Jij hebt al direct toegang tot Claude en je kan je eigen deployment-setup regelen.

Wat betekent dit voor jouw project?

Als je een MVP of early-stage SaaS bouwt met Claude Code in Next.js, ligt je app waarschijnlijk op Vercel of je draait 'm nog lokaal. Dat is prima voor stap één, maar zodra je echte gebruikers krijgt of kosten wil beheersen, loont het om te snappen hoe je op Google Cloud Run deployed. Dat is precies wat Lovable onder de motorkap doet: containerized apps op Google Cloud draaien. Jij kan dit zelf ook, met Claude Code als co-pilot.

Hoe je jouw Next.js app op Cloud Run krijgt met Claude Code

Hieronder de stappen die je vanavond kan doorlopen. Je hebt nodig: een werkende Next.js app (ook een simpele MVP is goed genoeg), een Google Cloud account (gratis tier werkt), en Claude Code open in je terminal.

Stap 1: laat Claude Code een Dockerfile genereren

Dit is de basis. Open Claude Code in de root van je project en stuur dit:

Maak een productie-klare Dockerfile voor mijn Next.js 14 app met App Router. Gebruik Node 20 alpine, multi-stage build (builder + runner), stel de PORT environment variable in op 8080, en zorg dat de image zo klein mogelijk is. Voeg ook een .dockerignore toe.

Claude Code genereert dan iets als:

# Stage 1: builder
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: runner
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV PORT=8080
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 8080
CMD ["node", "server.js"]

Controleer daarna of je next.config.js de standalone output-mode aan heeft staan, anders werkt bovenstaande niet:

// next.config.js
module.exports = {
  output: 'standalone',
}

Is mijn next.config.js klaar voor standalone output en Docker deployment op Cloud Run? Check het bestand en pas aan waar nodig.

Stap 2: laat Claude Code een deploy-script schrijven

Handmatig builden en pushen is tijdverspilling. Geef Claude Code deze prompt:

Schrijf een bash-script deploy.sh dat mijn app bouwt als Docker image, pushed naar Google Artifact Registry onder project-id PROJECT_ID, regio europe-west4, en daarna deployed naar Cloud Run als service met de naam mijn-saas-app. Voeg commentaar toe per stap zodat ik begrijp wat er gebeurt.

Je krijgt dan een script dat je eenmalig aanpast met je eigen project-id:

#!/bin/bash
set -e

PROJECT_ID="jouw-project-id"
REGION="europe-west4"
SERVICE="mijn-saas-app"
IMAGE="$REGION-docker.pkg.dev/$PROJECT_ID/apps/$SERVICE"

# Bouw de Docker image lokaal
echo "Bouwen..."
docker build -t $IMAGE .

# Push naar Artifact Registry
echo "Pushen naar Artifact Registry..."
docker push $IMAGE

# Deploy naar Cloud Run
echo "Deployen naar Cloud Run..."
gcloud run deploy $SERVICE \
  --image $IMAGE \
  --region $REGION \
  --platform managed \
  --allow-unauthenticated \
  --memory 512Mi \
  --max-instances 3

echo "Deploy klaar!"

Stap 3: environment variables veilig regelen

Je hebt waarschijnlijk een .env.local met API keys. Die mogen nooit in je Docker image. Vraag Claude Code:

Hoe stel ik mijn environment variables in voor mijn Cloud Run service zonder ze in mijn Docker image te zetten? Ik gebruik NEXT_PUBLIC_SUPABASE_URL, SUPABASE_SERVICE_KEY en STRIPE_SECRET_KEY. Geef me de exacte gcloud-commando's.

Claude Code geeft je dan de juiste gcloud run services update commando's met --set-env-vars of verwijst je naar Secret Manager als je het netter wil doen.

Stap 4: automatisch deployen bij elke push (optioneel maar slim)

Als je al een GitHub repo hebt, kan je dit uitbreiden:

Maak een GitHub Actions workflow .github/workflows/deploy.yml die automatisch mijn Cloud Run deploy-script uitvoert bij elke push naar de main branch. Gebruik Workload Identity Federation voor authenticatie (geen service account key in GitHub Secrets).

Dit is het verschil tussen een hobbyproject en een echte SaaS: automatische deploys zonder handwerk.

Wat te checken na afloop

• Draait je app op de Cloud Run URL die je kreeg na de deploy?
• Geeft gcloud run services describe mijn-saas-app --region europe-west4 een status van Ready?
• Laden je pagina's zonder 500-errors in de browser?
• Zijn je environment variables zichtbaar in de Cloud Run console (maar niet in je code)?
• Is je Docker image kleiner dan 500MB? (Zo niet, vraag Claude Code om de multi-stage build te optimaliseren.)

Als je op alle vijf een vinkje kan zetten, heb je dezelfde infrastructuur-basis als waar Lovable nu fors in investeert. Alleen dan gebouwd en beheerd door jou.