Reference
Code Generation
Everything ServiceGen materializes from a graph: source trees, contracts, commands, containers and Kubernetes deployment assets.
Generation model
What is generatedServiceGen creates service wiring, contracts, infrastructure and business extension points from the modeled architecture. Implementing the business behavior remains application work.
Graph + settings -> service workspaceGenerate project and ZIP downloadGenerate target-language services from the current graph through an authenticated asynchronous job.Graph -> generation job -> signed ZIP downloadRepository modelServices, modules and project orchestration have separate repository ownership and release coordinates.Workspace -> independently publishable repositoriesHow generated names are derivedDirectory names are derived from user-configured Project, Service, Module, Connector and Endpoint properties; names from the canonical example are not reserved conventions.Designer fields -> paths and identifiersRegeneration and file ownershipRegeneration replaces generator-owned files while preserving established business and customization files.generated basename + overwrite listMerge engine and hooksThe generated merge engine applies a complete ServiceGen archive to an existing workspace while preserving business files. Two user-owned executable hooks can customize individual file decisions and run project-wide work after installation.merge.generated.sh + user-owned hooksGenerated project structure
Workspace layoutThe root joins generated services, contracts, local infrastructure and operations into one reproducible workspace.
project rootGo projectGo generation produces small entrypoints, generated graph wiring and ordinary Go packages for business logic.service -> cmd + internal + modulesC++ projectC++ generation emits standalone CMake projects for CppUserver or CppCoro, with native runtime wiring, typed headers, tests and reusable build images.service -> CMake + cmd + internalPython projectPython generation creates independently buildable service and Module packages joined by root uv-based automation.workspace -> pyproject packagesRust projectRust generation creates a Cargo workspace whose services and contracts also build independently.workspace -> Cargo packagesTypeScript projectTypeScript generation creates independent npm packages joined by a root pnpm workspace.pnpm workspace -> npm packagesGenerated assets and ownership
Runtime wiring and business codeEach service separates topology-derived framework assembly from files intended for application development.
generated assembly + preserved extensionsModules, contracts and descriptorsThe graph materializes shared types, public functions and transport definitions inside Modules explicitly created and named by the user.graph references -> user-named ModuleConfiguration, graph and documentationEvery service carries enough generated metadata to connect runtime behavior back to the architecture.design-time graph -> runtime valuesLanguage build rootsThe root contains only the build systems required by the languages selected for its services and modules.workspace build graphGenerated scripts and toolsWorkspace scripts implement operations that are too stateful or detailed for portable Make recipes.scripts/*.generated.*CI and repository qualityGenerated components include repeatable CI definitions and repository-local quality gates.GitHub Actions + GitLab CIDashboards and monitoring assetsObservability assets are generated per service and provisioned consistently in Compose and Kubernetes.graph -> generated observabilityStandalone packagingPackaging targets extract a service and its declared contracts into a repository that no longer depends on the root workspace layout.workspace service -> dist/<service>Make commands
Workspace commandsThe root Makefile is a stable user entrypoint that includes generated orchestration and active language backends.
make <target>Repository and merge commandsGenerated targets publish independent repositories and safely reconcile a new archive with an existing workspace.make git-* / make merge-*Go commandsGo targets generate schemas, synchronize modules, build services and validate Temporal Workflow determinism.make golang-*C++ commandsC++ targets run the canonical CMake toolchain in Docker and expose Debug, Release and sanitizer matrices.make cpp-*Python commandsPython targets use uv for reproducible package setup, generation, testing, linting, images, integration checks, and standalone packaging.make python-*Rust commandsRust targets operate on the workspace while preserving the ability to build every crate independently.make rust-*TypeScript commandsTypeScript targets manage pnpm generation, builds, strict checks, diagnostics, profiling and standalone packaging.make typescript-*Docker and local infrastructure
Docker ComposeCompose files materialize the complete local topology and specialized build, integration, cache and Kubernetes profiles.
docker-compose*.ymlDevelopment and runtime imagesGenerated multi-stage images separate fast local development from minimal production-style execution.RUNTIME_IMAGE=0 | 1Dependency cacheThe generated cache makes repeated builds reproducible and reduces public-registry traffic across language ecosystems.Nexus + Git mirrorGeneration requests
Kubernetes and Helm
Local KubernetesThe project generates one local k3s environment and one registry, then installs every service through its independent Helm chart.
registry + k3s + HelmService Helm chartsEvery service owns an independently installable, observability-neutral Helm chart.<service>/helmConfiguration and secretsGenerated charts keep ordinary runtime configuration separate from operator-owned credentials.ConfigMap + secretEnvFromObservability and TemporalThe generated local cluster verifies metrics, dashboards, traces and logs against the same service identity used by Compose.Prometheus + Grafana + OTEL + Jaeger + LokiPackages and Modules
Module, package, and functionPackageThree similarly named fields control ownership, type alias metadata, and function placement at different levels.
module != package != functionPackagefunctionPackage pathsHow an empty value and a relative value map to generated function files in every target language.<functions_root>/<functionPackage>Public type ownershipHow ServiceGen selects the physical Module, import identity, type directory, and inferred package alias.publicType + module + package