Architecture
How serverless.au builds and serves your applications
Overview
serverless.au is built on four core services: an API server for orchestration, build workers for compilation, an edge runtime for server-side rendering, and object storage for assets. All services are written in Rust for performance and reliability.
When you deploy, your code flows through these services in sequence: the API receives the deployment request, a worker builds your project, assets are uploaded to storage, and the edge runtime serves requests to your users.
Deployment Pipeline
Deployments are triggered by GitHub webhooks or manual requests through the dashboard. Each deployment is an immutable snapshot of your application at a specific commit.
GitHub sends a push event to our API. We verify the webhook signature, extract the commit SHA and branch, and create a deployment record.
A build job is queued in our job table. Workers poll this queue and claim jobs atomically to prevent duplicate builds. Jobs are processed FIFO.
The worker clones your repository at the exact commit SHA using your GitHub access token. Private repositories are fully supported.
Your project is built inside an isolated Docker container. Environment variables marked for build-time use are decrypted and injected. The install command runs first, followed by your build command.
Built assets are uploaded to S3-compatible storage. Each deployment gets its own isolated directory, enabling instant rollbacks to any previous version.
The deployment is marked as production and begins receiving traffic. The previous deployment remains available for rollback.
Framework Detection
During project creation, we analyze your repository to detect the framework and suggest appropriate build settings. We look for configuration files, dependencies, and project structure to identify:
The framework type determines how your deployment is processed. Static sites are served directly from storage, while SSR frameworks run on our edge runtime.
Static Hosting
Static deployments serve pre-built HTML, CSS, JavaScript, and other assets directly from edge-cached storage. This is the fastest serving mode.
When a request arrives, we resolve your project from the hostname, look up the active deployment, and serve the requested file from storage. Assets with hashed filenames receive immutable cache headers for optimal browser caching.
For single-page applications, we implement SPA fallback routing: requests for paths without file extensions that don't match a static file are served your index.html, allowing client-side routing to handle the path.
Edge Runtime
Server-side rendered applications run on our edge runtime, which executes your server code in V8 isolates—the same JavaScript engine that powers Chrome and Node.js.
Each isolate is a lightweight, isolated execution environment. Unlike containers, isolates start in milliseconds and use minimal memory. We maintain a pool of warm isolates for each deployment to minimize cold start latency.
Isolates are evicted using LRU (least recently used) when the pool reaches capacity. High-traffic deployments stay warm; low-traffic deployments may experience occasional cold starts.
Request Handling
When a request hits the edge runtime, we follow this flow:
Environment Variables
Environment variables are encrypted at rest using AES-256-GCM. Each variable gets a unique nonce, and values are only decrypted when needed—during builds or at runtime in your isolate.
Variables can be scoped to control when they're available:
- Build only — Available during the build process, not at runtime
- Runtime only — Available in your server code, not during builds
- Both — Available in both contexts
You can also target variables to specific environments (production vs preview) to use different API keys or configurations for different deployment contexts.
Custom Domains
Custom domains require DNS verification before activation. We use a two-step verification process:
Add a TXT record to prove domain ownership. This prevents unauthorized users from claiming your domain.
Point your domain to our edge servers. Once DNS propagates, we automatically provision an SSL certificate via Let's Encrypt.
SSL certificates are issued within minutes of DNS verification and renew automatically. All traffic is served over HTTPS.
Logs & Metrics
All build output streams to our logging infrastructure in real-time. You can watch builds as they happen or query historical logs after completion.
Runtime logs from your application (console.log, console.error, etc.) are captured and stored with request context, making it easy to debug issues in production.
Request metrics are collected for every request to your deployment:
- Request count and rate over time
- Latency percentiles (p50, p95, p99)
- Cold vs warm boot times
- Cache hit rates for static assets
- Error rates by status code
Security Model
Security is enforced at multiple layers:
Each build runs in an isolated Docker container with no network access to other builds or internal systems. Containers are destroyed after the build completes.
V8 isolates provide memory isolation between requests and between different applications. One deployment cannot access another's memory or environment variables.
Isolates run with minimal permissions. File system access is disabled. Network access is allowed only for outbound HTTP requests. Only explicitly configured environment variables are accessible.
Environment variables are encrypted at rest. All traffic between services uses TLS. User data is stored in encrypted databases.