The short version: if it opens in a browser, it works on Porch. Porch serves static files — HTML, CSS, JavaScript, images, and fonts. No backend, no runtime. Here's exactly what that means.
The rule: if your app needs a running server to function — Node.js, Python, PHP, a database connection — it won't run on Porch without a separate backend. Everything that runs purely in the browser works.
Works great
What you can upload
These project types deploy and run on Porch with no extra configuration.
Single-file HTML apps
Claude artifacts, hand-written pages, AI-generated dashboards
Static HTML + CSS + JS folders
Any project that opens with index.html
React, Vue, Svelte — built to static
Export with vite build, next export, or similar
v0 exports
Build locally first, then upload the dist/ folder
Bolt.new projects
Download ZIP, npm run build, upload dist/
Lovable exports
Clone from GitHub, build, upload — Supabase client works too
CDN-loaded libraries
Chart.js, D3, Three.js, Leaflet via unpkg or jsDelivr
Inline data visualizations
Dashboards, charts, tables with data baked into the HTML
Interactive calculators & tools
Mortgage calculators, ROI tools, quiz apps
Client-side forms
Forms that email via Formspree, EmailJS, or similar SaaS
localStorage and sessionStorage
In-browser state that persists for that visitor
PWAs (Progressive Web Apps)
Service workers, offline-first apps — all supported
Embedded iframes and media
YouTube, Loom, Google Maps, Figma embeds
Client-side API calls
Fetch to any CORS-enabled API endpoint
Canvas and WebGL apps
Games, simulations, generative art
Supabase & Firebase client SDKs
Works when the anon key is included in the build
Markdown rendered client-side
Docs and READMEs rendered with marked.js or similar
Doesn't work
What Porch can't host
These require a running server. Use Railway, Fly.io, Render, or Vercel for the backend — then embed or link it from your Porch.
Node.js / Express / Fastify servers
Porch serves static files — no process stays running
Python, Ruby, PHP backends
Server-side languages need a separate host (Railway, Fly.io)
Server-side rendering at request time
SSR requires a running server; pre-render to static instead
WebSocket servers
Client-side WebSocket connections to an external server are fine — hosting a WS server is not
Database connections from the server
No Node.js process means no pg, mysql2, mongoose, Prisma, etc.
Private environment variables at runtime
Secrets can't stay secret in a static file — never embed API keys
Server-only OAuth callbacks
OAuth flows that POST to your own server won't work without a backend
File system writes
Browsers have no file system access — uploads to S3/R2 via a client SDK work fine
Cron jobs or background workers
No runtime to schedule anything — use a separate service
Works with caveats
Things to know before you upload
These work, but have common tripping points.
External API calls blocked by CORS
If the API doesn't send Access-Control-Allow-Origin: *, the browser will block the request. Use a proxy or a CORS-friendly SDK.
Next.js projects without static export
next build alone produces server-side code. Add output: 'export' to next.config.js, then run next build to get a static out/ folder.
Vite projects — upload dist/, not src/
Run npm run build first. Uploading the source folder will show a blank page.
Supabase row-level security
If your Supabase tables have RLS enabled, make sure your anon key and policies allow the intended access from a browser origin.
Large asset files
Individual file size limit is 50 MB. Total project storage depends on your plan. Video is better hosted on a CDN and embedded.
Apps that call restricted APIs
APIs that require server-to-server auth (secret keys, signed requests) can't be called directly from the browser safely.
Not sure? Quick test.
Duplicate your project folder. Delete everything except the built output (usually dist/, out/, or build/). Open index.html directly in your browser — no local server. If it works, it works on Porch.
We use analytics cookies to improve Porch. Privacy Policy