Other Deployments — Vercel, Cloudflare, VPS, and Decap CMS Strategy
Deploy Dax Pro beyond Netlify: Vercel, Cloudflare Pages, Azure Static Web Apps, VPS with Nginx, or cPanel. Understand why Decap CMS is easiest on Netlify and the subdomain strategy for using Decap CMS on any host.
The Deployment Landscape
Dax Pro produces static files. Any host that can serve HTML, CSS, and JavaScript can serve a Dax Pro site. That includes:
- Netlify — the recommended default. Covered in the previous chapter
- Vercel — similar to Netlify, optimized for frontend frameworks
- Cloudflare Pages — global edge network, generous free tier
- Azure Static Web Apps — Microsoft-native, fits .NET teams
- GitHub Pages — free, simple, no server-side features
- AWS S3 + CloudFront — enterprise-grade, requires more setup
- VPS with Nginx — full control, requires server administration
- cPanel shared hosting — traditional hosting, upload via FTP or File Manager
- Netlify Identity — a built-in authentication service
- Git Gateway — a built-in proxy that uses your personal access token
- An OAuth provider — GitHub OAuth, GitLab OAuth, or an external service like Auth0
- An OAuth proxy — a small server that handles the OAuth callback and exchanges the code for a token
- A commit endpoint — usually the same proxy, which accepts the content and commits it to GitHub
- Host the public site on your preferred platform (Vercel, Cloudflare, etc.)
- Host the admin panel on Netlify under a subdomain like
admin.example.com - Both build from the same GitHub repository
- Public site on whatever CDN you prefer (better performance in your region, lower cost, whatever the reason)
- Admin panel on Netlify, with Identity and Git Gateway, at a URL like
admin.example.com/admin/ - Public site benefits from whatever host you chose
- Admin panel benefits from Netlify's zero-config Identity
- No OAuth server to build
- Both environments stay in sync because they build from the same source
- Two hosting accounts to manage
- Two build pipelines to monitor
- Slightly more configuration
- GitHub backend setup
- OAuth client configuration
- Single host for everything
- No Netlify dependency
- Editors use GitHub accounts (which many developers already have)
- Editors must have GitHub accounts
- You must deploy and maintain the OAuth proxy
- More setup than Netlify Identity
- Works on any host
- No authentication to configure
- No OAuth proxy to deploy
- Editors need local access to the project folder (developer-only workflow)
- Editors need local development setup (Node.js, project access)
- Not suitable for non-technical editors
- Every change is a manual commit and push
The site itself deploys identically to all of these. The output is site/ — a folder of HTML files. Upload it, and the site works.
The complication is Decap CMS. On Netlify, Identity and Git Gateway handle authentication and Git commits with two clicks. On other hosts, you must either:
1. Configure a separate OAuth backend, or
2. Deploy the CMS admin panel separately, or
3. Use Decap CMS in local mode only, and use Git directly for content changes
This chapter covers all three strategies, plus deployment instructions for each major host.
Why Decap CMS Is Easiest on Netlify
Decap CMS needs two things that are not part of a static site:
1. Authentication — to know who is editing
2. A commit proxy — to write changes to GitHub on the editor's behalf
On Netlify, both are first-party:
On other hosts, neither is available. You must provide them yourself.
What you need on non-Netlify hosts:
Decap CMS documents this setup at decapcms.org/docs/backends-overview. It works, but it requires a small backend service — a Node.js or Go function deployed alongside the static site.
This is why Netlify is the recommended default. The complexity is hidden. On other hosts, you manage it yourself.
Strategy 1 — Deploy Everything on Netlify
If Decap CMS is a requirement, the simplest path is:
This gives you:
How it works:
1. Deploy the repository to Netlify (as covered in the previous chapter). This becomes the admin panel.
2. Configure a custom subdomain admin.example.com pointing to Netlify.
3. Edit public/admin/config.yml so the admin panel is only available at the subdomain. Restrict backend.branch and backend.base_url to the subdomain.
4. Deploy the same repository to your preferred host. This becomes the public site.
5. Point your public domain (example.com) at the preferred host.
6. Editors use admin.example.com/admin/. Content commits to GitHub. Both Netlify and the preferred host rebuild from the same repository. The public site updates.
Advantages:
Disadvantages:
When to use this strategy: you have a strong reason to host the public site elsewhere (cost, compliance, region, existing account), but you want Decap CMS to just work.
Strategy 2 — Deploy Decap CMS with GitHub OAuth
If you want to host everything on one platform and avoid Netlify, you need to implement GitHub OAuth yourself.
The setup:
1. Create a GitHub OAuth App at github.com/settings/developers
2. Deploy a small OAuth proxy (Node.js, Go, or a serverless function)
3. Configure Decap CMS to use the proxy
4. Editors log in with GitHub accounts (no Identity)
5. The proxy exchanges OAuth codes for tokens and commits content
Decap CMS documents this thoroughly:
The OAuth proxy — Decap CMS provides reference implementations. The popular one is vencax/netlify-cms-github-oauth-provider. It runs as a Node.js function on Vercel, Netlify Functions, or any Node.js host.
Advantages:
Disadvantages:
When to use this strategy: your team already uses GitHub, you want one host, and you are comfortable deploying a small OAuth service.
Strategy 3 — Use Decap CMS in Local Mode Only
The simplest strategy: do not use Decap CMS in production. Edit content locally with the CMS proxy, then push to Git manually.
How it works:
1. On your machine, run npx decap-server in one terminal and dotnet run -- start in another
2. Open http://localhost:8080/admin/ to use the CMS locally
3. Make edits, click Save, changes write to local files
4. Push to GitHub: git add . && git commit -m "Content update" && git push
5. Your host rebuilds
Advantages:
Disadvantages:
When to use this strategy: you are the only editor and you are technical. Or you have no editors and just want a static site.
Deployment Instructions by Host
Vercel
Vercel is the closest analog to Netlify. It supports static sites, GitHub integration, and preview deployments. It does not have built-in Identity.
Steps:
1. Push your project to GitHub
2. Go to vercel.com, log in with GitHub
3. Click Add New → Project
4. Import your Dax Pro repository
5. Vercel reads vercel.json if present. Dax Pro ships with one, which specifies the build command and output directory
6. Click Deploy
7. Vercel builds and deploys
What vercel.json contains:
{
"buildCommand": "dotnet publish -c Release -o bin && ./bin/DaxPro build",
"outputDirectory": "site",
"framework": null
}
Vercel does not automatically install .NET. You must add a build configuration that includes the .NET SDK. Vercel's build environment supports multiple runtimes; check Vercel's documentation for adding the .NET SDK to the build environment.
Alternatively, use a Docker-based build: create a Dockerfile that installs .NET and runs the build, then let Vercel build the container. This is more complex but more reliable.
For Decap CMS: Vercel does not provide Identity or Git Gateway. Use Strategy 1 (Netlify subdomain for admin) or Strategy 2 (GitHub OAuth proxy).
Cloudflare Pages
Cloudflare Pages is a static hosting service on Cloudflare's global network. It has generous free limits, fast global performance, and Git-based deployment.
Steps:
1. Push your project to GitHub
2. Go to pages.cloudflare.com, log in with Cloudflare account
3. Click Create a project → Connect to Git
4. Authorize Cloudflare to access your GitHub repository
5. Select the Dax Pro repository
6. Configure the build:
- Framework preset: None
- Build command: dotnet publish -c Release -o bin && ./bin/DaxPro build
- Build output directory: site
7. Click Save and Deploy
Cloudflare Pages environment: Cloudflare does not include .NET by default. Like Vercel, you need to install the SDK during the build. Cloudflare supports build environment variables that run setup scripts. The specifics depend on Cloudflare's current build environment capabilities — check the Cloudflare Pages documentation for adding custom runtimes.
For Decap CMS: same as Vercel — no Identity, no Git Gateway. Use Strategy 1 or 2.
Azure Static Web Apps
Azure Static Web Apps is Microsoft's static hosting service. It is a natural fit for .NET projects because Azure environments often already include the .NET SDK.
Steps:
1. Push your project to GitHub
2. In the Azure Portal, search for Static Web Apps
3. Click Create
4. Fill in the details:
- Subscription: your Azure subscription
- Resource group: create a new one
- Name: dax-pro or similar
- Plan type: Free (or Standard for custom authentication)
- Region: choose one near your audience
- Source: GitHub
- Organization: your GitHub username
- Repository: your Dax Pro repository
- Branch: main
5. Configure the build:
- Build presets: Custom
- App location: /
- API location: (leave empty)
- Output location: site
6. Click Review + create
7. Azure creates the Static Web App and sets up a GitHub Actions workflow in your repository
Build environment: Azure Static Web Apps reads the .github/workflows/ file it generates. The workflow uses actions/setup-dotnet to install .NET before the build. If your repository already has a workflow file, Azure may overwrite it. Backup your existing workflow.
For Decap CMS: Azure Static Web Apps has built-in authentication, but it is Azure AD / GitHub / Twitter based, not Netlify Identity. To use Decap CMS on Azure, use Strategy 2 (GitHub OAuth proxy) or host the admin panel on Netlify (Strategy 1).
GitHub Pages
GitHub Pages is free, simple, and integrated with GitHub. It has no server-side features, so Decap CMS in production is not practical without an external OAuth proxy.
Steps:
1. Push your project to GitHub
2. Create a GitHub Actions workflow in .github/workflows/deploy.yml:
name: Deploy Dax Pro
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with:
dotnet-version: '9.0.x'
- run: dotnet publish -c Release -o bin && ./bin/DaxPro build
- uses: actions/upload-pages-artifact@v3
with:
path: site
- uses: actions/deploy-pages@v4
with:
token: ${{ secrets.GITHUB_TOKEN }}
3. Commit and push
4. In the GitHub repository settings, go to Pages
5. Source: GitHub Actions
6. The first build deploys the site
For Decap CMS: GitHub Pages does not have Identity or Git Gateway. Use Strategy 1 (Netlify admin) or Strategy 3 (local only).
VPS with Nginx
A VPS gives you full control. You install a web server, upload the static files, and configure the domain.
Steps:
1. Provision a VPS — DigitalOcean, Linode, Hetzner, Vultr, AWS Lightsail, etc.
2. Install Nginx:
sudo apt update
sudo apt install nginx
3. Build the site locally:
dotnet run -- build
4. Upload the site/ folder to the VPS. Use rsync:
rsync -avz site/ user@your-vps:/var/www/dax-pro/
5. Configure Nginx:
server {
listen 80;
server_name example.com;
root /var/www/dax-pro;
index index.html;
location / {
try_files $uri $uri/ =404;
}
location /admin/ {
try_files $uri $uri/ /admin/index.html;
}
}
6. Reload Nginx:
sudo systemctl reload nginx
7. Set up HTTPS with Certbot:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com
For Decap CMS: a VPS can host both the site and an OAuth proxy, but you must deploy the proxy yourself. Use Strategy 2. Alternatively, host the admin panel on Netlify (Strategy 1) and use the VPS only for the public site.
cPanel Shared Hosting
cPanel hosting provides a file manager and FTP access. Static files can be uploaded directly.
Steps:
1. Build the site locally:
dotnet run -- build
2. Zip the site/ folder:
cd site
zip -r ../site.zip .
cd ..
3. Log in to cPanel
4. Open File Manager
5. Navigate to public_html/
6. Delete any existing files (or back them up)
7. Upload site.zip
8. Use cPanel's Extract to unzip in place
9. Delete site.zip after extraction
10. Visit https://yourdomain.com — the site is live
For Decap CMS: cPanel cannot host the OAuth proxy without Node.js support. Use Strategy 1 (Netlify admin) or Strategy 3 (local only).
The Subdomain Strategy in Detail
The strategy that works universally: admin panel on Netlify, public site on any host.
Architecture:
example.com — public site (on Vercel, Cloudflare, VPS, etc.)admin.example.com — admin panel (on Netlify)Both deploy from the same GitHub repository. Both build with dotnet run -- build. The difference is the subdomain — admin.example.com serves the /admin/ path, and example.com serves everything else.
How to configure:
1. Deploy the repository to Netlify (as covered in the previous chapter). This becomes the admin panel.
2. Configure a custom subdomain admin.example.com pointing to Netlify:
- In Netlify: Site configuration → Domain management → Add custom domain → admin.example.com
- In your DNS provider: add a CNAME record admin pointing to your Netlify site's .netlify.app domain
3. Deploy the same repository to your preferred host (Vercel, Cloudflare, VPS, etc.). This becomes the public site.
4. Configure the public domain example.com pointing to your preferred host:
- In your preferred host: add example.com as a custom domain
- In your DNS provider: add the records your host requires (usually an A record or CNAME)
5. Edit public/admin/config.yml in the repository to restrict the admin panel to the subdomain:
backend:
name: git-gateway
branch: main
base_url: https://admin.example.com
site_domain: admin.example.com
6. Rebuild and redeploy both environments. The admin panel is now only available at admin.example.com/admin/. If someone navigates to example.com/admin/, they get an error (or a redirect, depending on your configuration).
Why this works: Netlify Identity is bound to the Netlify site. When the admin panel is on admin.example.com (Netlify), the Identity login flow works. When the public site is on example.com (Vercel), it does not attempt to provide Identity. The two environments are independent but build from the same source.
Editors use admin.example.com/admin/. They log in with Netlify Identity. Changes commit to GitHub. Netlify rebuilds the admin panel (no visible change) and your preferred host rebuilds the public site (change visible).
Comparing the Strategies
| Strategy | Public Site | Admin Panel | Complexity | Editor Experience |
|---|---|---|---|---|
| All on Netlify | Netlify | Netlify | Low | Best — one login, one URL |
| Admin on Netlify subdomain | Any host | Netlify | Medium | Good — two URLs, one login |
| GitHub OAuth proxy | Any host | Any host | High | Medium — editors need GitHub accounts |
| Local CMS only | Any host | Local | Low | Developer-only |
Recommendation: For most projects, all on Netlify is the simplest and works well. If you have a specific reason to host the public site elsewhere, admin on Netlify subdomain is the next best option.
Use GitHub OAuth proxy only if you cannot use Netlify at all.
Use local CMS only only if you are the sole editor and you are technical.
Common Deployment Mistakes
Mistake 1: Deploying to Vercel or Cloudflare without .NET SDK.
The build environment does not include .NET by default. The build fails with "SDK not found." You must either use a Docker-based build, add a setup step, or host on Netlify/Azure (which include .NET).
Mistake 2: Attempting Decap CMS on a host without Identity.
Decap CMS needs authentication and a commit proxy. Without Netlify Identity, you must provide both. Editors see a login screen that does not work.
Mistake 3: Forgetting the /admin/ path in Nginx.
Nginx does not serve /admin/ as an index by default. The try_files $uri $uri/ /admin/index.html; rule in the Nginx config handles this. Without it, /admin/ returns 404.
Mistake 4: Uploading to the wrong directory on shared hosting.
cPanel sites usually live in public_html/. Uploading to / or /home/ does nothing. Upload to public_html/ and extract.
Mistake 5: Not updating config.yml for subdomains.
If you deploy the admin panel to admin.example.com, the backend.base_url and backend.site_domain must reflect this. Without them, the Identity flow may fail or editors may be redirected to the wrong URL.
Mistake 6: Mixing public and admin paths on the wrong host.
Do not serve /admin/ from the public site (Vercel, Cloudflare). The Identity flow expects the admin panel to be on the host that provides Identity (Netlify). Serve /admin/ only from Netlify.
Mistake 7: Not configuring HTTPS on custom hosts.
VPS and cPanel deployments require explicit HTTPS setup (Certbot for Nginx, AutoSSL for cPanel). Without HTTPS, editor sessions fail (mixed content, insecure cookies).
Mistake 8: Forgetting to rebuild after config.yml changes.
Changes to config.yml require a rebuild. The build copies public/admin/config.yml to site/admin/config.yml. If you change the source but do not rebuild, the deployed config is the old one.
What You Have Now
After this chapter, you can:
The site is deployed and editable. The next chapter covers Custom Domains — connecting your own domain to Netlify (or your chosen host), setting up DNS, and enabling HTTPS.
→ Continue to Custom Domain