Skip to content

Actix Todos

A REST API for managing todos, built with Rust/Actix-web and PostgreSQL using SQLx. Demonstrates deploying a database-backed Rust application on AppMecca.

Overview
Repository git@gitlab.com:appmecca-sample-apps/actix-todos.git
Tech Stack Rust 1.84 / Actix-web / SQLx
Services api (port 8080)
Database Yes
Cache None
URL Pattern https://actix-todos-api.{env}.appmecca.net

What This App Demonstrates

  • Deploying a database-backed Rust application on AppMecca
  • SQLx with compile-time checked SQL queries
  • Rust multi-stage Docker builds with database dependencies
  • REST API with full CRUD operations against PostgreSQL
  • The database: enabled: true configuration pattern

appmecca.yaml

containers:
  - name: api
    dockerfile: Dockerfile
    context: .

deploy:
  - name: api
    container: api
    port: 8080
    health_check:
      path: /health

database:
  enabled: true

The only addition compared to Hello Rust is database: enabled: true. AppMecca provisions a PostgreSQL database on first deploy and injects DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASSWORD, and DATABASE_URL into the container automatically. Read DATABASE_URL — the database and user names are generated identifiers, not derived from the app name.

Step-by-Step Deployment

1. Register the app

mecca register git@gitlab.com:appmecca-sample-apps/actix-todos.git -e dev

2. Build the container

mecca build trigger -e dev -g git@gitlab.com:appmecca-sample-apps/actix-todos.git
Expected output 
Build started: build-xxxxxxxx
Cloning repository...
Building container: api
Pushing image to the private registry: actix-todos/api
Build complete. Duration: 150s

Rust builds are slow the first time because the compiler downloads and compiles all dependencies (including SQLx and Actix-web) from source. Subsequent builds with cached Docker layers are faster.

3. Deploy

mecca app deploy -e dev actix-todos
Expected output 
Deploying actix-todos to dev...
Deployment queued: deploy-xxxxxxxx
Waiting for agents...
Container started: actix-todos-api
Health check passed: /health -> 200 OK
Deployment complete.

Services:
  api: https://actix-todos-api.dev.appmecca.net

4. Verify

mecca queue status takes the action ID printed when you deployed, not the app name:

mecca queue status <action-id> -e dev

To look up the app itself — including the exact URL for your group — use:

mecca app show actix-todos -e dev

Test the API:

# Health check
curl https://actix-todos-api.dev.appmecca.net/health

{"status": "healthy"}

# Create a todo
curl -X POST https://actix-todos-api.dev.appmecca.net/api/todos \
  -H "Content-Type: application/json" \
  -d '{"title": "Deploy more apps", "done": false}'

# List all todos
curl https://actix-todos-api.dev.appmecca.net/api/todos

# Update a todo
curl -X PUT https://actix-todos-api.dev.appmecca.net/api/todos/1 \
  -H "Content-Type: application/json" \
  -d '{"done": true}'

# Delete a todo
curl -X DELETE https://actix-todos-api.dev.appmecca.net/api/todos/1

API Endpoints

Method Path Description
GET /health Health check
GET /api/todos List all todos
POST /api/todos Create a todo
PUT /api/todos/:id Update a todo
DELETE /api/todos/:id Delete a todo

Key Concepts

SQLx for Rust (compile-time checked queries)

SQLx is an async Rust SQL library that verifies your SQL queries at compile time against a real database schema. This means typos in column names, type mismatches, and invalid SQL are caught during cargo build rather than at runtime. For Docker builds where no database is available, SQLx supports an offline mode -- running cargo sqlx prepare generates a .sqlx/ directory with cached query metadata that the build stage uses instead of a live database connection.

Rust multi-stage builds with database apps

The Dockerfile adds libpq-dev to the build stage so that SQLx can link against the PostgreSQL client library. The runtime stage needs only libpq5 (the runtime library, not the development headers). The entrypoint script runs embedded SQL migrations via sqlx migrate run before starting the Actix-web server. Combined with the compiled binary, the final image remains small (~35 MB) despite the database dependency.

Any language, same workflow

AppMecca does not care what language your application is written in. As long as your container listens on the declared port and responds to health checks, the deployment workflow is identical.

What's Next?