This page covers the development workflow, build processes, containerization, testing strategies, and operational procedures for maintaining Sim Studio. It serves as a high-level guide for developers to set up their environment and understand the lifecycle of code from local development to production deployment.
Sim Studio utilizes a monorepo structure managed by Turbo and Bun, with distinct development modes for local iteration and full-stack testing.
Sources: package.json7-10 apps/sim/package.json1-5 apps/docs/package.json1-5
The root package.json and apps/sim/package.json expose scripts for various development tasks:
| Command | Location | Description |
|---|---|---|
bun run dev | Root | Starts all applications in development mode using Turbo. |
bun run dev:full | apps/sim | Starts the Next.js app, Socket.io server, and BullMQ worker concurrently. |
bun run dev:sockets | apps/sim | Runs the standalone Socket.io server at socket/index.ts. |
bun run worker | apps/sim | Runs the background worker at worker/index.ts. |
bun run lint | apps/sim | Runs biome to check and auto-fix code style. |
bun run test | apps/sim | Executes the vitest test suite. |
Sources: package.json11-27 apps/sim/package.json10-34
For detailed environment configuration and service setup, see Development Setup.
The CI/CD pipeline is orchestrated via GitHub Actions, handling everything from linting to multi-architecture Docker builds.
Sources: .github/workflows/ci.yml1-52 .github/workflows/test-build.yml1-20 package.json44-48
husky and lint-staged are used to run Biome checks before every commit.linux/amd64 and linux/arm64.For details on automation and release procedures, see CI/CD Pipeline.
Sim Studio is designed to run in containerized environments using Docker and Kubernetes.
The system is split into several functional containers to allow independent scaling:
| Service | Dockerfile | Responsibility |
|---|---|---|
simstudio | app.Dockerfile | Main Next.js web application and API. |
sim-worker | app.Dockerfile | Background job processing (BullMQ) using worker/index.ts. |
realtime | realtime.Dockerfile | Collaborative editing server (Socket.io). |
migrations | db.Dockerfile | Runs db:migrate on startup to update PostgreSQL. |
db | pgvector/pgvector | Database with vector search capabilities. |
Sources: docker-compose.prod.yml1-134 docker/app.Dockerfile1-145 docker/realtime.Dockerfile1-84
Production deployments typically require significant memory (8GB+ for the main app) due to the heavy AI and workflow execution logic. Standalone builds are used to minimize image size by excluding unnecessary node_modules.
For details on resource limits and multi-stage builds, see Docker & Containerization.
The codebase uses vitest for unit and integration testing. Tests are co-located or placed in __tests__ directories. The CI pipeline enforces coverage requirements to ensure critical execution paths (like DAGExecutor) remain stable.
Sources: apps/sim/package.json24-26 .github/workflows/test-build.yml30-50
For details on mocking patterns and test utilities, see Testing Strategy.
Sim uses Drizzle ORM for schema management. Migrations are generated as SQL files and applied during the deployment process via a dedicated migration container.
Sources: package.json33 apps/sim/package.json112 docker-compose.prod.yml107-117
For details on evolving the schema, see Database Migrations.
.cursorrules and .claude/ instructions to help AI assistants maintain architectural consistency when adding new blocks or integrations. See AI Coding Assistant Rules.Sources: package.json apps/sim/package.json docker/app.Dockerfile docker-compose.prod.yml .github/workflows/ci.yml
Refresh this wiki