Use case
One repo with /frontend and /backend. You want each workspace to bring up both services with isolated ports and a predictable URL per service.
Use this when frontend and backend live in one repo and both run directly on your machine.
One repo with /frontend and /backend. You want each workspace to bring up both services with isolated ports and a predictable URL per service.
frontend
apiSeparate services keep the frontend and backend stable per workspace and prevent them colliding across branches.
cd frontend && npm i
cd ../backend && pip install -r requirements.txt
cp .env.example .envBootstraps both app layers. The setup script runs in a shell, so chained cd && ... steps work here. Copying .env gives each workspace its own config; a symlink would centralize updates but could cause cross-workspace side effects. Swap .env.example for whatever seed file your repo keeps, Spaces has no built-in shared env file.
Add two processes. Process commands run as shell input, so cd plus an env assignment runs naturally.
# frontend process
cd frontend && API_URL=$SPACES_API_URL PORT=$SPACES_FRONTEND_PORT npm run dev# backend process
cd backend && python manage.py runserver 0.0.0.0:$SPACES_API_PORTThe frontend points at the workspace's own backend service, so both processes share the workspace's per-service variables.
Add two browser sessions, each its own entry, so the frontend preview and the Django admin are each one focus away.
# frontend browser session
$SPACES_FRONTEND_URL# backend browser session
$SPACES_API_URL/admin