Platform Science Labs

Deploy to Cloudflare Pages

Ship internal tools and POCs to {repo-name}.labs.platformscience.com — protected by Okta, deployed on every push to main.

This site is deployed and protected

You're viewing this page because you authenticated with your @platformscience.com Okta account. All labs sites are restricted to Platform Science employees.

How it works

You add a small workflow file to your repo
On every push to main, your public/ folder deploys to Cloudflare Pages
A Zero Trust Access policy is automatically created, requiring Okta login
Your app is live at {repo-name}.labs.platformscience.com

Get started

Put your static site in a public/ folder at the root of your repo. At minimum, include an index.html.

Add the workflow file at .github/workflows/deploy-cloudflare-pages.yml:

name: Deploy to Cloudflare Pages

on:
  push:
    branches:
      - main

jobs:
  deploy:
    uses: PlatformScience-Labs/.github/.github/workflows/deploy-cloudflare-pages.yml@main
    with:
      deploy_dir: public
    secrets:
      CLOUDFLARE_LABS_API_TOKEN: ${{ secrets.CLOUDFLARE_LABS_API_TOKEN }}
      CLOUDFLARE_ACCESS_API_TOKEN: ${{ secrets.CLOUDFLARE_ACCESS_API_TOKEN }}

Download workflow file

Push to main. That's it. Your site will be live in under a minute.

Customization

Change the deploy directory by updating deploy_dir:

    with:
      deploy_dir: public   # or dist, build, out, etc.

Access control

All labs sites require authentication via Okta SSO
Only @platformscience.com accounts can access any labs site
Sessions last 24 hours before re-authentication is required
Access policies are managed centrally — no per-repo configuration needed

What you can deploy

Supported

Static sites (HTML/CSS/JS)	Drop files in `public/`, push, done
Single-page apps (React, Vue, Angular, Svelte)	Add a build step, output to `public/`
Next.js	Fully supported via `@cloudflare/next-on-pages` — SSR, API routes, middleware all work on the edge
Astro	Static or SSR mode both work
Vite / Remix / SvelteKit	Supported with Cloudflare adapters
Pages Functions (Workers)	Put JS/TS files in a `functions/` directory — they become API endpoints at the same domain
Server-side rendering	Runs on Cloudflare's edge runtime (V8 isolates, not Node.js)
WebSockets	Supported via Durable Objects or Workers
Cron triggers	Supported via Workers scheduled events
KV / D1 / R2 storage	Bind to Pages Functions for key-value, SQLite, or object storage

Not supported

Docker containers	Pages runs V8 isolates, not containers
Long-running processes	Workers have a 30s CPU limit (unbounded on paid plan for Durable Objects)
Node.js APIs (Express, Fastify, etc.)	Workers runtime is V8-based — most Node APIs are unavailable
Databases (Postgres, MySQL, etc.)	No managed relational DB hosting (D1 provides SQLite at the edge)
Background jobs / queues	No built-in job queue (Cloudflare Queues is in beta)
File uploads > 100MB	Pages has a 25MB per-file limit; Workers body limit is 100MB
Native binaries / FFmpeg / ImageMagick	No shell or binary execution
Python / Go / Rust backends	Workers only run JS/TS (Rust via WASM is possible but limited)

If your project needs any of the above, reach out to the infrastructure team for guidance on where to deploy your app.

Build limits

Max files per deployment	20,000
Max file size	25 MB
Build timeout	20 minutes
Deployments per day	500 (Free), unlimited (Enterprise)
Workers invocations	100K/day (Free), unlimited (Enterprise)

Rule of thumb: If your project is a frontend, static site, or lightweight API — it works on Cloudflare Pages. If it needs containers, long-running processes, a real database, or Node.js runtime — talk to the infrastructure team.

Architecture

Hosting: Cloudflare Pages
Auth: Cloudflare Zero Trust Access + Okta IdP
Routing: Cloudflare Pages custom domain on {repo}.labs.platformscience.com — served directly, no proxy needed
CI/CD: GitHub Actions reusable workflow in PlatformScience-Labs/.github
Secrets: Org-level GitHub secrets — individual repos never touch Cloudflare tokens