cloud

Production-oriented Vix backend application.

This project is generated by:

vix new cloud --template backend --api-only

It is designed as a simple production backend starter built around:

• vix::App
• vix.app
• .env configuration
• route and middleware registries
• JSON health endpoints
• production diagnostics

Quick start

cd cloud
cp .env.example .env
vix dev

Check the API:

curl http://127.0.0.1:8080/api
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/api/health

Project layout

include/cloud/
  app/
    AppBootstrap.hpp
  support/
    HttpResponses.hpp

src/
  main.cpp
  cloud/
    app/
      AppBootstrap.cpp
    application/
    domain/
    infrastructure/
    presentation/
      controllers/
        HomeController.hpp
        HomeController.cpp
        HealthController.hpp
        HealthController.cpp
      middleware/
        MiddlewareRegistry.hpp
        MiddlewareRegistry.cpp
      routes/
        RouteRegistry.hpp
        RouteRegistry.cpp
    support/
      HttpResponses.cpp

storage/
migrations/
tests/

.env
.env.example
vix.app
vix.json
README.md

Entry point

main.cpp stays minimal. The application bootstrapping logic lives in AppBootstrap.

#include <cloud/app/AppBootstrap.hpp>

int main()
{
  cloud::app::AppBootstrap bootstrap;
  return bootstrap.run();
}

Application bootstrap

AppBootstrap creates the Vix app, loads .env, registers middleware, registers routes, and starts the server.

main.cpp
  -> AppBootstrap
      -> vix::config::Config
      -> vix::App
      -> MiddlewareRegistry
      -> RouteRegistry
      -> app.run(cfg)

Routes

Routes are registered from:

src/cloud/presentation/routes/RouteRegistry.cpp

Generated routes:

GET /api
GET /health
GET /api/health

Middleware

Middleware is registered from:

src/cloud/presentation/middleware/MiddlewareRegistry.cpp

The generated middleware registry installs:

• security headers
• request logging
• an X-API: true marker header for /api routes

Recommended middleware order for real applications:

CORS -> rate limit -> request logging -> security headers -> body limits -> auth -> routes

Configuration

Start by copying the example environment file:

cp .env.example .env

Important defaults:

APP_NAME=cloud
APP_ENV=development
SERVER_PORT=8080
DATABASE_ENGINE=sqlite
DATABASE_SQLITE_PATH=storage/cloud.db
VIX_ORM_DIR=migrations
WEBSOCKET_ENABLED=false

Configuration sources

This template intentionally keeps one Vix production configuration source:

vix.json

vix.json describes what Vix needs to orchestrate the project:

• service generation
• Nginx proxy configuration
• health checks
• deployment workflow
• logs
• production ports
• required environment variables

Runtime values and secrets stay in:

.env
.env.example

Rule:

vix.json      -> Vix orchestration config
.env          -> local runtime values and secrets
.env.example  -> documented expected variables

This backend template does not generate config/production.json to avoid two competing production configuration files.

Build manifest

This project uses vix.app as its application manifest. Vix generates an internal CMake project automatically under:

.vix/generated/app/

Do not edit the generated CMake project manually. Edit vix.app instead.

Common commands

vix dev
vix build
vix check --tests --run
vix tests
vix run

Production workflow

vix.json is the production control file for Vix. It contains tasks and settings for service, proxy, health checks, logs, deploys, ports, environment requirements, and database defaults.

Useful commands:

vix build --preset release
vix check --tests --run
vix env check --production
vix health local
vix logs
vix deploy

Depending on which production tools are installed in your Vix version, you may also use:

vix service install
vix proxy nginx init
vix doctor production

ORM and migrations

The project includes a migrations/ directory and .env defaults for vix orm.

Examples:

vix orm status
vix orm migrate
vix orm rollback --steps 1

API-only mode

This project does not generate public/ or views/, and AppBootstrap does not configure static files or templates. Host your frontend separately and call the API routes from it.

Notes

• Keep main.cpp minimal.
• Register routes through RouteRegistry.
• Register middleware through MiddlewareRegistry.
• Keep reusable helpers under support/.
• Put business logic under application/ and domain/ as the app grows.
• Put database, files, and external services under infrastructure/.

Founding Supporters

Softadastra Cloud is in active development as a C++ cloud workspace for Vix projects, private packages, lockfiles, build reports, permissions, notifications and team activity. The Founding Supporters program is an early way to support that work before the full paid platform is ready.

There are two simple tiers: Founding Supporter at $10/month and Founding Builder at $25/month. Payments are handled through external payment links configured in the environment, and supporter records are currently confirmed and linked manually after payment. Softadastra Cloud does not store card details, payment metadata, or private billing information in this MVP step.

Public supporter records can appear on /supporters when public_visible is enabled. Supporter badges can also appear on public user profiles, but only for active supporters who have chosen public visibility.