smythos-studio is a visual agent builder that also ships its own execution runtime

Three packages, and the runtime is the part that matters

The repository structure section describes a monorepo with three packages, and the third one is what separates this from a canvas demo. The app package, packages/app, is the main application containing the visual builder, the React frontend and the backend services, with a visual agent builder for drag-and-drop workflows, a React frontend, a RESTful backend API for agent management and execution, and real-time testing for instant agent testing and debugging. The middleware package holds the core API services and database management, using a Prisma-based ORM with MySQL support and a centralized business logic and data access layer. The runtime package is the execution server that uses SRE Core Engine to execute the agents, and it is described as handling multiple concurrent agent executions, offering real-time debugging and monitoring, and supporting embodiment, which means deploying agents as chatbots, APIs and integrations. The user interface is where you design, and the runtime is where the design actually runs, and both ship together.

The visual-first argument is about who is allowed to build the workflow

The stated design principles are worth reading as a position rather than a feature list. The project compares itself to modern IDEs, saying that just as modern IDEs make software development accessible, SmythOS UI is meant to make AI agent development intuitive, and the visual-first section says the approach makes agent development accessible to everyone, from business analysts who understand the processes to developers who need to scale them to production. The feature list that follows names real-time testing, one-click deployment from development to production, an extensible architecture for custom components and integrations, and collaborative development with shared agent projects. The second of the three reasons given for the project is the no-code to pro-code path, where you start with visual building and extend with custom code when needed. The third is the open architecture claim, build once, deploy anywhere with complete control over your infrastructure, which is what the runtime package and the Docker setup exist to make concrete.

The Docker path gets a running instance on port 6060

The quick start offers two methods, and the Docker one is the shortest path to a working instance. You clone the repository, copy the compose environment file to .env, and bring the stack up.

git clone https://github.com/SmythOS/smythos-studio.git
cd smythos-studio
cp .env.compose.example .env
docker compose up -d

The application is then reachable at http://localhost:6060. The Docker Compose guide is described as covering container deployment with automatic SSL, database and caching, and it also has its own troubleshooting section that the quick start points to for setup problems. The compose file itself shows the shape of the deployment. Traefik sits in front as the reverse proxy, configured as a Docker provider with exposed-by-default disabled, a web entrypoint on port 80 and a websecure entrypoint on port 443, and a Let's Encrypt certificates resolver whose storage is a named volume. The dashboard and access log are enabled in the shipped configuration with comments marking them as optional, which is a useful signal about what the defaults are tuned for.

Local development needs MySQL, a .env file and pnpm

The second method is for development, customization and contributing, and it is the one that shows the real dependency list. You clone, copy .env.example to .env, edit the .env with your database credentials, install dependencies with pnpm, and start the development servers with pnpm dev.

# Clone the repository
git clone https://github.com/SmythOS/smythos-studio.git
cd smythos-studio

# Copy environment configuration
cp .env.example .env
# Edit .env with your database credentials

# Install dependencies
pnpm install

# Start development servers
pnpm dev

The next steps in the documentation are specific and worth reading before you start, since they are the parts that are easy to miss. You configure your MySQL database in .env, you set up the required subdomains for embodiments, and then you start building. The subdomain point matters, because the environment file defines DEFAULT_AGENT_DOMAIN and PROD_AGENT_DOMAIN as localagent.stage.smyth.ai, a public domain that loops back to localhost with a wildcard rule matching subdomains to 127.0.0.1, and an AGENT_DOMAIN_PORT for when the agent runs on a port other than 80 or 443. The development servers run in parallel across the workspace packages, since the root script is pnpm --parallel --recursive dev.

The environment file names the ports the whole stack assumes

The .env.example is the most informative file in the repository for understanding the deployment, and it is short. The database settings are MySQL, with a host, user, password and name, and the DATABASE_URL is assembled from those values with a port of 3306 and the flags allowPublicKeyRetrieval=true and useSSL=false. A comment marks that entry as mandatory for Prisma to work, and the reason is that the Prisma client is generated at build time in the Dockerfile. The port layout is fixed: APP_PORT is 5050, RUNTIME_PORT is 5053, APP_DEV_SERVER_PORT is 5051 and MIDDLEWARE_API_PORT is 5000, with APP_URL and RUNTIME_URL pointing at the matching local addresses. The Dockerfile confirms the exposure, with EXPOSE 5050 5053. Two more entries matter for a self-hosted install, SMYTHOS_EDITION is set to self-hosted, and OPENAI_API_KEY holds the model provider key.

The container image is Node 22 Alpine with pnpm and Prisma handled at build time

The Dockerfile shows how the pieces fit, and a few choices are worth noting. The base image is node:22-alpine, and the Alpine variant needs extra packages for Prisma, so openssl, openssl-dev, libc6-compat, ca-certificates and curl are installed with apk. The root package files and the TypeScript config are copied first, then pnpm is installed globally at the version the packageManager field pins, which is [email protected]. All package source is copied and dependencies are installed with pnpm install --frozen-lockfile, followed by a store prune and a cleanup of the pnpm store and caches. The build runs pnpm run build across the workspace, and then the Prisma client is generated inside packages/middleware with a commented-out line showing the musl OpenSSL binary target that Alpine would otherwise need. A data directory is created for the node user with an empty vault.json in it, ownership is moved to the node user, and the entrypoint script is copied in and made executable. The container finally runs as the node user, not root, with the entrypoint as its command.

A sibling project exists for people who would rather write code

The README points readers who do not want the canvas to a different repository, SmythOS Runtime, SDK and CLI, and the note says that if you prefer to build agents with code, or you want to run your visual agents on your local PC without overhead, you should check that project. That distinction is the one to hold on to when evaluating this one. SmythOS Studio is the visual surface plus the platform services around it, including the app, the middleware and the runtime package, and the topics attached to the repository include no-code, orchestration, agentic-ai, mcp-client and a2a, which describes the interoperability surface rather than the visual editor alone. The studio is therefore the heavyweight option, and the sibling is the lightweight one, and picking between them is a question of whether the visual builder is the point or the obstacle.

Where smythos-studio is the wrong choice

The first wrong case is a small automation that does not need a visual surface. Every workflow you draw here is a database row, a canvas edge and a runtime execution, and a hundred lines of TypeScript against a model API is cheaper to run, easier to test and far easier to review than the same logic expressed as a graph. The second wrong case is a project that cannot take a MySQL dependency, since the middleware package is built on a Prisma-based ORM with MySQL support and the environment file treats the database URL as mandatory, so a Postgres-only or SQLite-only deployment is a fork, not a configuration. The third is a team that needs a supported release channel, because the repository publishes no GitHub releases, the root package.json sits at version 1.0.1, and the last push was on 2026-04-03, which is more than six months before this article was written. The fourth is an air-gapped or restricted network, where the OPENAI_API_KEY entry and the model provider assumption make the deployment model hard to reconcile with a policy that forbids outbound calls to a hosted model.

Editorial conclusion

Teams that want to design agent workflows visually and then host the execution layer themselves, rather than hand the whole thing to a vendor platform, are the people smythos-studio is for, and the fact that the runtime package sits in the same monorepo as the canvas is the reason to look at it. It is the wrong tool for a team that wants a small dependency-free script, for a project that cannot run MySQL, and for anyone who needs a stable release cadence, because the repository publishes no GitHub releases and the last push was on 2026-04-03. Check three things before you commit: that the SRE core engine dependency in packages/runtime resolves for your deployment, since the runtime executes agents through it, that your environment file sets the database URL as the .env.example insists is mandatory for Prisma to work, and that the port layout in the compose file matches your reverse proxy, since the app listens on 5050 and the runtime on 5053 behind Traefik. The licence file is MIT, though the root package.json declares ISC, so confirm which terms apply before redistributing.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. SmythOS/smythos-studio on GitHub