dygo is a source-available framework for building serious business software in Go.
It is designed for business processes, internal operating systems, enterprise applications, and workflow-heavy products where permissions, metadata-driven schema, audit trails, observability, background jobs, secure configuration, and a consistent Studio UI matter from day one.
The goal is speed with structure: builders should focus on business logic while dygo handles the platform foundation.
dygo is released under the O'Saasy License. It is free to use, modify, self-host, and build with, but competing hosted, managed, SaaS, or cloud services where dygo itself is the primary value are reserved for the original licensor.
dygo is in early framework development.
The current repository contains the first Go module, CLI entrypoint, config defaults, HTTP server, encrypted credentials, app/entity metadata validation, PostgreSQL schema sync, Core metadata registry, metadata API, session auth, generic Record API foundation with system Record naming, and Record permission enforcement. The framework APIs are not stable yet.
The intended installer is:
curl -fsSL https://dygo.dev/install | shUntil dygo.dev/install is wired, use:
curl -fsSL https://raw.githubusercontent.com/dygo-dev/dygo/main/scripts/install.sh | shgo run ./cmd/dygo
go run ./cmd/dygo new my-company
go run ./cmd/dygo upgrade
go run ./cmd/dygo version
go run ./cmd/dygo doctor
go run ./cmd/dygo serve
go run ./cmd/dygo serve --env staging
go run ./cmd/dygo setup admin
go run ./cmd/dygo db check
go run ./cmd/dygo db create
go run ./cmd/dygo db drop --confirm development/dygo
go run ./cmd/dygo db prepare
go run ./cmd/dygo db reset --confirm development/dygo
go run ./cmd/dygo db schema dump
go run ./cmd/dygo migrate plan
go run ./cmd/dygo migrate
go run ./cmd/dygo fixtures apply
go run ./cmd/dygo schema prune
go run ./cmd/dygo schema prune --confirm development/dygo
go run ./cmd/dygo apps list
go run ./cmd/dygo apps validate
go run ./cmd/dygo entities list
go run ./cmd/dygo entities validate
go run ./cmd/dygo hooks generate sales lead
go run ./cmd/dygo secrets init
go run ./cmd/dygo secrets edit
go run ./cmd/dygo secrets validate
go run ./cmd/dygo secrets rotate-key --confirm my-company/master.keygo run ./cmd/dygo serve starts dygo on 127.0.0.1:6790. In this source checkout it also starts the Studio development asset server internally and proxies Studio through the same dygo origin.
The default server address is:
127.0.0.1:6790The first HTTP endpoints are:
GET /health
POST /api/v1/auth/login
POST /api/v1/auth/logout
GET /api/v1/auth/me
GET /api/v1/apps
GET /api/v1/apps/{app}
GET /api/v1/entities
GET /api/v1/entities/{entity}/meta
GET /api/v1/records/{entity}
GET /api/v1/records/{entity}/{id}
GET /api/v1/records/{entity}/{id}/activity
POST /api/v1/records/{entity}
PATCH /api/v1/records/{entity}/{id}
DELETE /api/v1/records/{entity}/{id}The API endpoints are generic and metadata-powered; dygo does not create separate handlers for each Entity. {entity} is the Entity route slug, defaulting to Entity name.
Metadata and Record APIs require an authenticated Studio session. Metadata visibility is permission-aware, and Record routes check Entity actions through the permission engine.
Scoped Record Activity is read through the target Record route and checked against the target Entity's read permission.
Project-aware commands discover the dygo root by walking upward from the current directory. Generated projects use dygo.yml as the root marker; the framework repository is also recognized during development.
dygo new <name> creates a project with one app under apps/, a project-local cmd/dygo runner, encrypted secrets, a development DATABASE_URL secret, and cached Studio UI assets when the running dygo build has them. It does not create a database, run schema sync, apply fixtures, or create the first Administrator; run the printed first-run commands before opening Studio.
Requirements:
- Go 1.26.2+
Verify the repo:
go test ./...
go test -race ./...
go vet ./...cmd/dygo/ executable entrypoint
internal/cli/ private CLI implementation
internal/config/ private config defaults and loading code
internal/db/ private PostgreSQL code
apps/ first-party dygo apps such as core and Studio
configs/ safe committed config files
db/ generated schema snapshot
docs/ project doctrine, thesis, and structure notes- Documentation Index
- Installation
- The dygo Doctrine
- Platform Thesis
- Nomenclature
- App Model
- App Manifest
- Entity Metadata
- Metadata Authoring
- Config
- Database
- Explicit Patches
- Fixtures
- Server
- Auth
- Records
- Studio
- Encrypted Secrets
- Contributing
- Documentation Strategy
- Directory Structure
Roadmap work is tracked in GitHub Projects:
Repository/project metadata for maintainers and agents lives in configs/github.yml.