Edge deployment
Skill itallstartedwithaidea/agent-skills/skills/web-frontend/edge-deployment
Edge Deployment automates the deployment of frontend applications to Vercel and Cloudflare with auto-detection of 40+ frameworks, intelligent build configuration, and environment-specific settings.From its SKILL.md
npx -y skills add itallstartedwithaidea/agent-skills --skill edge-deploymentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
5.2 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it
Edge Deployment
Part of Agent Skills™ by googleadsagent.ai™
Description
Edge Deployment automates the deployment of frontend applications to Vercel and Cloudflare with auto-detection of 40+ frameworks, intelligent build configuration, and environment-specific settings. The agent identifies the framework, configures the build pipeline, sets up environment variables, and deploys with zero manual configuration for standard projects.
Modern edge platforms eliminate the need for traditional server provisioning. This skill encodes the deployment patterns for both static (SSG) and server-rendered (SSR) applications across Vercel and Cloudflare Pages/Workers. The agent selects the optimal deployment strategy based on the framework's rendering capabilities, the project's data requirements, and the target platform's runtime constraints.
The skill handles the full deployment lifecycle: initial setup, preview deployments for pull requests, production deployments on merge, custom domain configuration, and environment variable management. It understands the differences between Vercel's serverless functions and Cloudflare Workers' edge runtime, routing to the appropriate platform based on project needs.
Use When
- Deploying a new frontend project for the first time
- Configuring CI/CD for preview and production deployments
- Migrating between deployment platforms (Vercel to Cloudflare or vice versa)
- Setting up custom domains and SSL certificates
- Configuring environment variables for different deployment stages
- Optimizing build settings for faster deploys
How It Works
graph TD
A[Project Source] --> B[Detect Framework]
B --> C{Framework Type}
C -->|Next.js/Nuxt/SvelteKit| D[SSR Deployment]
C -->|Astro/Vite/CRA| E[Static Deployment]
D --> F{Target Platform}
E --> F
F -->|Vercel| G[Configure vercel.json]
F -->|Cloudflare| H[Configure wrangler.jsonc]
G --> I[Set Build Command + Output Dir]
H --> I
I --> J[Configure Env Variables]
J --> K[Deploy Preview on PR]
K --> L[Deploy Production on Merge]
Framework detection examines package.json dependencies, config files, and directory structure. The agent maps each framework to its optimal build command, output directory, and runtime configuration.
Implementation
Vercel Deployment
{
"framework": "nextjs",
"buildCommand": "next build",
"outputDirectory": ".next",
"regions": ["iad1", "sfo1", "lhr1"],
"env": {
"DATABASE_URL": "@database-url",
"API_KEY": "@api-key"
}
}
# Deploy to Vercel
npx vercel --prod
# Preview deployment
npx vercel
# Set environment variable
npx vercel env add DATABASE_URL production
Cloudflare Pages Deployment
// wrangler.jsonc
{
"name": "my-app",
"pages_build_output_dir": "./dist",
"compatibility_date": "2026-04-01",
"vars": {
"ENVIRONMENT": "production"
}
}
# Deploy to Cloudflare Pages
npx wrangler pages deploy ./dist --project-name=my-app
# Preview deployment
npx wrangler pages deploy ./dist --project-name=my-app --branch=feature-x
GitHub Actions CI/CD
name: Deploy
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: "20" }
- run: npm ci
- run: npm run build
- if: github.event_name == 'push'
run: npx wrangler pages deploy ./dist --project-name=my-app
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CF_API_TOKEN }}
Best Practices
- Use preview deployments for every PR to catch issues before production
- Store secrets in the platform's encrypted environment variable system, never in code
- Pin framework and runtime versions to avoid build drift between environments
- Configure caching headers at the edge for static assets (1 year for hashed files)
- Use platform-specific adapters (e.g.,
@sveltejs/adapter-cloudflare) for SSR - Monitor build times and set alerts for regressions above your baseline
Platform Compatibility
| Platform | Support | Notes |
|---|---|---|
| Cursor | Full | Shell tool for CLI deploys |
| VS Code | Full | Vercel/CF extensions available |
| Windsurf | Full | Deployment workflow support |
| Claude Code | Full | CLI-based deployments |
| Cline | Full | Terminal integration |
| aider | Partial | Config file generation only |
Related Skills
Keywords
edge-deployment vercel cloudflare-pages ci-cd framework-detection static-deployment ssr-deployment preview-deployment
© 2026 googleadsagent.ai™ | Agent Skills™ | MIT License
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most containers cloud skills give in ~1.2k tokens
Counted across 607 of the 705 authors here whose files we hold, read 2026-09-06
- Run as non-root userin 34 of 607, across 27 files
- Use multi-stage buildsin 29 of 607
- Set resource requests and limitsin 24 of 607, across 20 files
- Configure liveness and readiness probesin 18 of 607, across 14 files
- Use named volumes for persistent datain 14 of 607, across 9 files
- Pin base image versionsin 14 of 607
- Set up environment variablesin 14 of 607, across 10 files
- Pin provider versionsin 14 of 607
- Apply least privilege RBAC permissionsin 10 of 607, across 7 files
- Create a dockerignore filein 10 of 607
- Use remote state with lockingin 9 of 607
- Pin base images by digestin 9 of 607, across 8 files
Said here and by no other author read
- Use preview deployments for every pull request
- Pin framework and runtime versions
- Configure caching headers at the edge
- Use platform-specific adapters for server side rendering
- Monitor build times and set alerts
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.