The GitHub templates behind every Apso backend
Every backend Apso generates starts from a service template: a working GitHub repository with the framework, database wiring, and local development environment already in place. The templates are public, Apache-2.0 licensed, and the code they produce runs with or without Apso.
Three languages, one workflow
TypeScript
NestJS, TypeORM, PostgreSQL
Includes Swagger documentation, request validation with class-validator, Docker Compose scripts for a local database, and a PGlite sandbox that tests schema migrations before they touch a real database.
apso init --name my-api --language typescriptPython
FastAPI, SQLAlchemy 2, PostgreSQL
Async from the ground up with asyncpg, Alembic migrations, and Pydantic v2 models for request and response validation.
apso init --name my-api --language pythonGo
Gin, GORM, PostgreSQL
Includes goose migrations, Swagger documentation via swaggo, and idiomatic Go project structure.
apso init --name my-api --language goHow a template becomes your backend
Clone
apso init clones the template for your language, installs dependencies, and initializes git. One command, no manual setup.
Define
You describe entities and relationships in a .apsorc schema file. The schema is the source of truth for your whole backend.
Generate
apso generate writes entities, services, controllers, and migrations into the template's autogen directory. Your own code lives in extensions and is never touched.
A template you keep, not a platform you rent
The generated code is standard framework code in your repository. There is no Apso SDK in the output and no runtime dependency on Apso. Regenerate when your schema changes, extend it by hand in the extensions directory, or stop using Apso entirely. The backend keeps working either way.
Build your first backend from a template
The quickstart takes a schema to a running API in about ten minutes.