Full-Stack App Design on Eve Horizon
Architect applications where the manifest is the blueprint, the platform handles infrastructure, and every design decision is intentional.
When to Use
Load this skill when:
- Designing a new application from scratch on Eve
- Migrating an existing app onto the platform
- Evaluating whether your current architecture uses Eve's capabilities well
- Planning service topology, database strategy, or deployment pipelines
- Deciding between managed and external services
This skill teaches design thinking for Eve's PaaS layer. For CLI usage and operational detail, load the corresponding eve-se skills (eve-manifest-authoring, eve-deploy-debugging, eve-auth-and-secrets, eve-pipelines-workflows).
The Manifest as Blueprint
The manifest (.eve/manifest.yaml) is the single source of truth for your application's shape. Treat it as an architectural document, not just configuration.
What the Manifest Declares
| Concern |
Manifest Section |
Design Decision |
| Service topology |
services |
What processes run, how they connect |
| Infrastructure |
services[].x-eve |
Managed DB, ingress, roles |
| Build strategy |
services[].build + registry |
What gets built, where images live |
| Release pipeline |
pipelines |
How code flows from commit to production |
| Environment shape |
environments |
Which environments exist, what pipelines they use |
| Agent configuration |
x-eve.agents, x-eve.chat |
Agent profiles, team dispatch, chat routing |
| Runtime defaults |
x-eve.defaults |
Harness, workspace, git policies |
Design principle: If an agent or operator can't understand your app's shape by reading the manifest, the manifest is incomplete.
Service Topology
Choose Your Services
Most Eve apps follow one of these patterns:
API + Database (simplest):
services:
api: # HTTP service with ingress
db: # managed Postgres
API + Worker + Database:
services:
api: # HTTP service (user-facing)
worker: # Background processor (jobs, queues)
db: # managed Postgres
Multi-Service:
services:
web: # Frontend/SSR
api: # Backend API
worker: # Background jobs
db: # managed Postgres
redis: # external cache (x-eve.external: true)
Service Design Rules
- One concern per service. Separate HTTP serving from background processing. An API service should not also run scheduled jobs.
- Use managed DB for Postgres. Declare
x-eve.role: managed_db and let the platform provision, connect, and inject credentials. No manual connection strings.
- Mark external services explicitly. Use
x-eve.external: true with x-eve.connection_url for services hosted outside Eve (Redis, third-party APIs).
- Use
x-eve.role: job for one-off tasks. Migrations, seeds, and data backfills are job services, not persistent processes.
- Expose ingress intentionally. Only services that need external HTTP access get
x-eve.ingress.public: true. Internal services communicate via cluster networking.
App Object Storage
Apps that need to store files (uploads, avatars, exports) can declare object store buckets in the manifest:
services:
api:
x-eve:
object_store:
buckets:
- name: uploads
visibility: private
- name: avatars
visibility: public
Note: The database schema for app object stores exists, but automatic provisioning from the manifest is not yet wired. See references/object-store-filesystem.md for current status.
When wired, the platform injects STORAGE_ENDPOINT, STORAGE_ACCESS_KEY, STORAGE_SECRET_KEY, STORAGE_BUCKET, and STORAGE_FORCE_PATH_STYLE into the service container.
Cloud FS / Google Drive Storage
For document-oriented storage, use cloud FS mounts. Each org connects its own Google Drive via BYOA OAuth credentials, then mounts folders into the org filesystem:
eve integrations configure google-drive --client-id "..." --client-secret "..."
eve integrations connect google-drive
eve cloud-fs mount --org org_xxx --provider google-drive --folder-id <id> --label "Shared Drive"
Apps can browse and search mounted Drive content through Eve's Cloud FS surface (eve cloud-fs ls, eve cloud-fs search, and the per-mount Cloud FS API routes). This is complementary to object store buckets -- use cloud FS for shared documents and collaboration, use object store for app-managed binary assets.
Platform-Injected Variables
Every deployed service receives EVE_API_URL, EVE_PUBLIC_API_URL, EVE_PROJECT_ID, EVE_ORG_ID, and EVE_ENV_NAME. Use EVE_API_URL for server-to-server calls. Use EVE_PUBLIC_API_URL for browser-facing code. Design your app to read these rather than hardcoding URLs.
Reference Architecture: SPA + API + Managed DB
The most common Eve fullstack pattern. A nginx-fronted SPA proxies API calls to an internal backend, with managed Postgres and eve-migrate for schema management.
Service Layout
services:
web: # nginx SPA (public ingress, proxies /api/ → api service)
api: # NestJS/Express backend (internal, no public ingress)
db: # managed Postgres 16
migrate: # eve-migrate job (runs SQL migrations)
Why nginx proxy? The web service's nginx reverse-proxies /api/ to the internal API service. This eliminates CORS, removes the need for hard-coded API hostnames, and gives the SPA same-origin access to the backend. The API service has no public ingress — it's only reachable inside the cluster.
Manifest Shape
services:
api:
build:
context: ./apps/api
dockerfile: ./apps/api/Dockerfile
ports: [3000]
environment:
NODE_ENV: production
DATABASE_URL: ${managed.db.url}
CORS_ORIGIN: "https://myapp.eh1.incept5.dev"
web:
build:
context: ./apps/web
dockerfile: ./apps/web/Dockerfile
ports: [80]
environment:
API_SERVICE_HOST: ${ENV_NAME}-api
depends_on:
api:
condition: service_healthy
x-eve:
ingress:
public: true
port: 80
alias: myapp
migrate:
image: public.ecr.aws/w7c4v0w3/eve-horizon/migrate:latest
environment:
DATABASE_URL: ${managed.db.url}
MIGRATIONS_DIR: /migrations
x-eve:
role: job
files:
- source: db/migrations
target: /migrations
db:
x-eve:
role: managed_db
managed:
class: db.p1
engine: postgres
engine_version: "16"
The nginx Proxy
The web service Dockerfile builds the SPA with Vite, then serves it via nginx. The nginx config uses envsubst to resolve ${API_SERVICE_HOST} at container startup:
server {
listen 80;
root /usr/share/nginx/html;
index index.html;
location /api/ {
proxy_pass http://${API_SERVICE_HOST}:3000/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
}
location / {
try_files $uri $uri/ /index.html;
}
location /health {
return 200 "ok";
add_header Content-Type text/plain;
}
}
In the manifest, API_SERVICE_HOST: ${ENV_NAME}-api resolves to the k8s service name (e.g., sandbox-api), giving nginx a stable internal DNS target.
Eve-Migrate for Schema Management
Eve provides a purpose-built migration runner at public.ecr.aws/w7c4v0w3/eve-horizon/migrate:latest. It uses plain SQL files with timestamp prefixes, tracked in a schema_migrations table (idempotent, checksummed, transactional).
db/
migrations/
20260312000000_initial_schema.sql
20260312100000_seed_data.sql
20260315000000_add_status_column.sql
Mount migrations into the container via x-eve.files. The migrate step in the pipeline runs after deploy (the managed DB must be provisioned first).
Do not use TypeORM, Knex, or Flyway migrations — they add complexity and diverge from the Eve platform's migration tracking. The eve-migrate runner gives parity between local dev and staging.
Multi-Stage Dockerfiles
API Dockerfile (NestJS/Node):
FROM node:22-slim AS base
WORKDIR /app
ENV PNPM_HOME="/pnpm" PATH="$PNPM_HOME:$PATH"
RUN corepack enable && corepack prepare pnpm@latest --activate
FROM base AS deps
COPY package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile 2>/dev/null || pnpm install
FROM deps AS build
COPY tsconfig.json ./
COPY src ./src
RUN pnpm build
FROM node:22-slim AS production
WORKDIR /app
RUN groupadd --gid 1000 node || true && useradd --uid 1000 --gid node --shell /bin/bash --create-home node || true
COPY --from=deps /app/node_modules ./node_modules
COPY
