diff --git a/.env.example b/.env.example
index 8a9e87f65..60c3ec58a 100644
--- a/.env.example
+++ b/.env.example
@@ -2,14 +2,8 @@
 
 # This would be set to the production domain with an env var on deployment
 
-# used by Traefik to transmit traffic and aqcuire TLS certificates
-
 DOMAIN=localhost
 
-# To test the local Traefik config
-
-# DOMAIN=localhost.tiangolo.com
-
 # Environment: "development", "testing", "staging", "production"
 
 ENVIRONMENT=development
diff --git a/.github/ISSUE_TEMPLATE/enhancement_request.md b/.github/ISSUE_TEMPLATE/enhancement_request.md
new file mode 100644
index 000000000..2b120f908
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/enhancement_request.md
@@ -0,0 +1,20 @@
+---
+name: Enhancement request
+about: Suggest an improvement to existing codebase
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the current behavior**
+A clear description of how it currently works and what the limitations are.
+
+**Describe the enhancement you'd like**
+A clear and concise description of the improvement you want to see.
+
+**Why is this enhancement needed?**
+Explain the benefits (e.g., performance, usability, maintainability, scalability).
+
+**Additional context**
+Add any other context, metrics, screenshots, or examples about the enhancement here.
diff --git a/.github/workflows/cd-production.yml b/.github/workflows/cd-production.yml
index 3a1d0edfe..ee2f965c7 100644
--- a/.github/workflows/cd-production.yml
+++ b/.github/workflows/cd-production.yml
@@ -1,4 +1,4 @@
-name: Deploy AI Platform to ECS Production
+name: Deploy Kaapi to ECS Production
 
 on:
   push:
diff --git a/.github/workflows/cd-staging.yml b/.github/workflows/cd-staging.yml
index 10d9ccde9..44743d660 100644
--- a/.github/workflows/cd-staging.yml
+++ b/.github/workflows/cd-staging.yml
@@ -1,4 +1,4 @@
-name: Deploy AI Platform to ECS
+name: Deploy Kaapi to ECS
 
 on:
   push:
diff --git a/.github/workflows/continuous_integration.yml b/.github/workflows/continuous_integration.yml
index fb2d9c80d..dac6f791e 100644
--- a/.github/workflows/continuous_integration.yml
+++ b/.github/workflows/continuous_integration.yml
@@ -1,4 +1,4 @@
-name: AI Platform CI
+name: Kaapi CI
 
 on:
   push:
@@ -22,7 +22,7 @@ jobs:
 
     strategy:
       matrix:
-        python-version: ["3.11.7"]
+        python-version: ["3.12"]
         redis-version: [6]
 
     steps:
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 31515b205..26e535cb6 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,13 +1,13 @@
-# Contributing to Tech4Dev AI Platform
+# Contributing to Kaapi
 
-Thank you for considering contributing to **Tech4Dev AI Platform**! We welcome contributions of all kinds, including bug reports, feature requests, documentation improvements, and code contributions.
+Thank you for considering contributing to **Kaapi**! We welcome contributions of all kinds, including bug reports, feature requests, documentation improvements, and code contributions.
 
 ---
 
 ## 📌 Getting Started
 To contribute successfully, you must first set up the project on your local machine. Please follow the instructions outlined in the project's README to configure the repository and begin your contributions.
 
-Before you proceed, **make sure to check the repository's [README](https://github.com/ProjectTech4DevAI/ai-platform/blob/main/backend/README.md) for a comprehensive overview of the project's backend and detailed setup guidelines.**
+Before you proceed, **make sure to check the repository's [README](https://github.com/ProjectTech4DevAI/kaapi-backend/blob/main/backend/README.md) for a comprehensive overview of the project's backend and detailed setup guidelines.**
 
 ---
 
@@ -17,10 +17,18 @@ Before you proceed, **make sure to check the repository's [README](https://githu
 1. Click the **Fork** button on the top right of this repository.
 2. Clone your forked repository:
 ```
-git clone https://github.com/{username}/ai-platform.git
-cd ai-platform
+git clone https://github.com/{username}/kaapi-backend.git
+cd kaapi-backend
 ```
 
+### Check for Existing Issues
+Before you start working on a contribution:
+1. **Check if an issue exists** for the bug or feature you want to work on in the [Issues](https://github.com/ProjectTech4DevAI/kaapi-backend/issues) section.
+2. **If no issue exists**, create one first using the templates present:
+   - For bugs: Use the bug report template
+   - For enhancements: Use the enhancement request template
+   - For features: Create a feature request issue
+
 ### Create a Branch
 • Always work in a new branch based on main.
 • For branch name, follow this convention: ``type/one-line-description``
@@ -30,12 +38,9 @@ cd ai-platform
    - enhancement
    - bugfix
    - feature
-
-
  ```
  git checkout -b type/one-line-description
  ```
-
 ### Make and Test Changes
 1. Adhere to the project's established coding style for consistency.
 2. Make sure the code adheres to best practices.
@@ -60,7 +65,7 @@ git commit -m "one liner for the commit"
 • For PR name, follow this convention:
    ``Module Name: One liner of changes``
 
-• Don't forget to link the PR to the issue if you are solving one.
+• Don't forget to link the PR to the issue.
 
 • Push your changes to GitHub:
 ```
diff --git a/README.md b/README.md
index 316d490d8..8bb525c46 100644
--- a/README.md
+++ b/README.md
@@ -1,11 +1,11 @@
-# AI Platform
+# Kaapi
 
 [![License: AGPL v3](https://img.shields.io/badge/License-AGPL%20v3-blue.svg)](https://www.gnu.org/licenses/agpl-3.0)
-![](https://github.com/ProjectTech4DevAI/ai-platform/workflows/Continuous%20Integration/badge.svg)
-[![Code coverage badge](https://img.shields.io/codecov/c/github/ProjectTech4DevAI/ai-platform/staging.svg)](https://codecov.io/gh/ProjectTech4DevAI/ai-platform/branch/staging)
-![GitHub issues](https://img.shields.io/github/issues-raw/ProjectTech4DevAI/ai-platform)
-[![codebeat badge](https://codebeat.co/badges/dd951390-5f51-4c98-bddc-0b618bdb43fd)](https://codebeat.co/projects/github-com-ProjectTech4DevAI/ai-platform-staging)
-[![Commits](https://img.shields.io/github/commit-activity/m/ProjectTech4DevAI/ai-platform)](https://img.shields.io/github/commit-activity/m/ProjectTech4DevAI/ai-platform)
+![](https://github.com/ProjectTech4DevAI/kaapi-backend/workflows/Continuous%20Integration/badge.svg)
+[![Code coverage badge](https://img.shields.io/codecov/c/github/ProjectTech4DevAI/kaapi-backend/staging.svg)](https://codecov.io/gh/ProjectTech4DevAI/kaapi-backend/branch/staging)
+![GitHub issues](https://img.shields.io/github/issues-raw/ProjectTech4DevAI/kaapi-backend)
+[![codebeat badge](https://codebeat.co/badges/dd951390-5f51-4c98-bddc-0b618bdb43fd)](https://codebeat.co/projects/github-com-ProjectTech4DevAI/kaapi-backend-staging)
+[![Commits](https://img.shields.io/github/commit-activity/m/ProjectTech4DevAI/kaapi-backend)](https://img.shields.io/github/commit-activity/m/ProjectTech4DevAI/kaapi-backend)
 
 ## Pre-requisites
 
diff --git a/backend/README.md b/backend/README.md
index 0bdbd8c75..27671dafe 100644
--- a/backend/README.md
+++ b/backend/README.md
@@ -1,4 +1,4 @@
-# FastAPI Project - Backend
+# Kaapi - Backend
 
 ## Requirements
 
@@ -27,13 +27,15 @@ $ source .venv/bin/activate
 
 Make sure your editor is using the correct Python virtual environment, with the interpreter at `backend/.venv/bin/python`.
 
-Modify or add SQLModel models for data and SQL tables in `./backend/app/models.py`, API endpoints in `./backend/app/api/`, CRUD (Create, Read, Update, Delete) utils in `./backend/app/crud.py`.
+Modify or add SQLModel models for data and SQL tables in `./backend/app/models/`, API endpoints in `./backend/app/api/`, CRUD (Create, Read, Update, Delete) utils in `./backend/app/crud/`.
 
-## VS Code
+## Seed Database (Optional)
 
-There are already configurations in place to run the backend through the VS Code debugger, so that you can use breakpoints, pause and explore variables, etc.
+For local development, seed the database with baseline data:
 
-The setup is also already configured so you can run the tests through the VS Code Python tests tab.
+```console
+$ uv run python -m app.seed_data.seed_data
+```
 
 ## Docker Compose Override
 
@@ -91,6 +93,22 @@ Nevertheless, if it doesn't detect a change but a syntax error, it will just sto
 
 ## Backend tests
 
+### Setup Test Environment
+
+Before running tests, create a test environment configuration:
+
+1. Copy the test environment template:
+```console
+$ cp .env.test.example .env.test
+```
+
+2. Update `.env.test` with test-specific settings:
+   - Set `ENVIRONMENT=testing`
+   - Configure a separate test database (recommended). Using a separate
+     database prevents tests from affecting your development data.
+
+### Run Tests
+
 To test the backend run:
 
 ```console
@@ -133,7 +151,7 @@ Make sure you create a "revision" of your models and that you "upgrade" your dat
 $ docker compose exec backend bash
 ```
 
-* Alembic is already configured to import your SQLModel models from `./backend/app/models.py`.
+* Alembic is already configured to import your SQLModel models from `./backend/app/models/`.
 
 * After changing a model (for example, adding a column), inside the container, create a revision, e.g.:
 
diff --git a/deployment.md b/deployment.md
index b75a42137..cdf22fd90 100644
--- a/deployment.md
+++ b/deployment.md
@@ -1,309 +1,236 @@
-# AI Platform - Deployment
+# Kaapi - Deployment
 
-You can deploy the project using Docker Compose to a remote server.
+Kaapi uses a modern cloud-native deployment architecture built on AWS services with automated CI/CD pipelines.
 
-This project expects you to have a Traefik proxy handling communication to the outside world and HTTPS certificates.
+## Deployment Architecture
 
-You can use CI/CD (continuous integration and continuous deployment) systems to deploy automatically, there are already configurations to do it with GitHub Actions.
+### Overview
 
-But you have to configure a couple things first. 🤓
+The deployment follows a containerized approach where:
+- Application code is packaged into Docker images
+- Images are stored in AWS ECR (Elastic Container Registry)
+- ECS (Elastic Container Service) runs and manages the containers
+- GitHub Actions automates the build and deployment process
 
-## Preparation
+### CI/CD Pipeline
 
-* Have a remote server ready and available.
-* Configure the DNS records of your domain to point to the IP of the server you just created.
-* Configure a wildcard subdomain for your domain, so that you can have multiple subdomains for different services, e.g. `*.fastapi-project.example.com`. This will be useful for accessing different components, like `dashboard.fastapi-project.example.com`, `api.fastapi-project.example.com`, `traefik.fastapi-project.example.com`, `adminer.fastapi-project.example.com`, etc. And also for `staging`, like `dashboard.staging.fastapi-project.example.com`, `adminer.staging..fastapi-project.example.com`, etc.
-* Install and configure [Docker](https://docs.docker.com/engine/install/) on the remote server (Docker Engine, not Docker Desktop).
+The deployment pipeline is triggered automatically:
+1. **Code Push**: Developer pushes code to GitHub
+2. **Build**: GitHub Actions builds Docker image
+3. **Push**: Image is pushed to ECR
+4. **Deploy**: ECS pulls new image and updates running tasks
 
-## Public Traefik
+### Environments
 
-We need a Traefik proxy to handle incoming connections and HTTPS certificates.
+Two deployment environments are configured:
+- **Staging**: Deployed on every push to `main` branch for testing
+- **Production**: Deployed only on version tags for stable releases
 
-You need to do these next steps only once.
+## Prerequisites
 
-### Traefik Docker Compose
+Before deploying, ensure the following AWS infrastructure exists:
 
-* Create a remote directory to store your Traefik Docker Compose file:
+### AWS Infrastructure
 
-```bash
-mkdir -p /root/code/traefik-public/
-```
+1. **ECS Clusters**: Separate clusters for staging and production environments
+2. **ECR Repositories**: Container image repositories for each environment
+3. **ECS Task Definitions**: Define container configurations, resource limits, and environment variables
+4. **ECS Services**: Manage the desired number of running tasks
+5. **IAM Role for GitHub**: Allows GitHub Actions to authenticate via OIDC (no long-lived credentials)
+6. **RDS PostgreSQL**: Managed database service (recommended for production)
+7. **ElastiCache Redis**: Managed Redis for caching (optional)
+8. **Amazon MQ RabbitMQ**: Managed message broker for Celery (optional)
 
-Copy the Traefik Docker Compose file to your server. You could do it by running the command `rsync` in your local terminal:
+### GitHub Setup
 
-```bash
-rsync -a docker-compose.traefik.yml root@your-server.example.com:/root/code/traefik-public/
-```
+Configure GitHub to allow automated deployments:
 
-### Traefik Public Network
+1. **Environment**: Create `AWS_ENV_VARS` environment for deployment protection
+2. **Variable**: Set `AWS_RESOURCE_PREFIX` to identify your AWS resources
 
-This Traefik will expect a Docker "public network" named `traefik-public` to communicate with your stack(s).
+## AWS Resource Naming Convention
 
-This way, there will be a single public Traefik proxy that handles the communication (HTTP and HTTPS) with the outside world, and then behind that, you could have one or more stacks with different domains, even if they are on the same single server.
+All AWS resources follow a consistent naming pattern using `AWS_RESOURCE_PREFIX` as the base identifier.
 
-To create a Docker "public network" named `traefik-public` run the following command in your remote server:
+This naming convention ensures clear separation between environments and easy identification of resources.
 
-```bash
-docker network create traefik-public
-```
+## Deployment Workflows
 
-### Traefik Environment Variables
+### Staging Deployment
 
-The Traefik Docker Compose file expects some environment variables to be set in your terminal before starting it. You can do it by running the following commands in your remote server.
+**Purpose**: Automatically deploy changes to a testing environment for validation before production.
 
-* Create the username for HTTP Basic Auth, e.g.:
+**Trigger**: Push to `main` branch
 
 ```bash
-export USERNAME=admin
+git push origin main
 ```
 
-* Create an environment variable with the password for HTTP Basic Auth, e.g.:
+**Workflow Steps** (`.github/workflows/cd-staging.yml`):
+1. **Checkout**: Clone the repository code
+2. **AWS Authentication**: Use OIDC to authenticate (no stored credentials)
+3. **ECR Login**: Authenticate to container registry
+4. **Build**: Create Docker image from `./backend` directory
+5. **Push**: Upload image to staging ECR repository with `latest` tag
+6. **Deploy**: Force ECS to pull and deploy the new image
 
-```bash
-export PASSWORD=changethis
-```
+The deployment typically completes in 5-10 minutes depending on image size and ECS configuration.
 
-* Use openssl to generate the "hashed" version of the password for HTTP Basic Auth and store it in an environment variable:
+### Production Deployment
 
-```bash
-export HASHED_PASSWORD=$(openssl passwd -apr1 $PASSWORD)
-```
-
-To verify that the hashed password is correct, you can print it:
-
-```bash
-echo $HASHED_PASSWORD
-```
+**Purpose**: Deploy stable, tested versions to the production environment.
 
-* Create an environment variable with the domain name for your server, e.g.:
+**Trigger**: Create and push a version tag
 
 ```bash
-export DOMAIN=fastapi-project.example.com
-```
+# Create a version tag
+git tag v1.0.0
 
-* Create an environment variable with the email for Let's Encrypt, e.g.:
-
-```bash
-export EMAIL=admin@example.com
+# Push the tag to trigger deployment
+git push origin v1.0.0
 ```
 
-**Note**: you need to set a different email, an email `@example.com` won't work.
+**Workflow Steps** (`.github/workflows/cd-production.yml`):
+1. **Checkout**: Clone the repository at the tagged version
+2. **AWS Authentication**: Use OIDC to authenticate
+3. **ECR Login**: Authenticate to container registry
+4. **Build**: Create Docker image from `./backend` directory
+5. **Push**: Upload image to production ECR repository with `latest` tag
+6. **Deploy**: Force ECS to pull and deploy the new image
 
-### Start the Traefik Docker Compose
+**Best Practice**: Use semantic versioning (e.g., `v1.0.0`, `v1.2.3`) to clearly identify releases.
 
-Go to the directory where you copied the Traefik Docker Compose file in your remote server:
+## GitHub Configuration
 
-```bash
-cd /root/code/traefik-public/
-```
+### Step 1: Create Environment
 
-Now with the environment variables set and the `docker-compose.traefik.yml` in place, you can start the Traefik Docker Compose running the following command:
+Environments in GitHub provide deployment protection and organization.
 
-```bash
-docker compose -f docker-compose.traefik.yml up -d
-```
+1. Go to repository **Settings → Environments**
+2. Click **New environment**
+3. Name it: `AWS_ENV_VARS`
+4. Optionally, add protection rules (e.g., required reviewers)
 
-## Deploy the FastAPI Project
+### Step 2: Set Repository Variable
 
-Now that you have Traefik in place you can deploy your FastAPI project with Docker Compose.
+Variables store non-sensitive configuration that workflows need.
 
-**Note**: You might want to jump ahead to the section about Continuous Deployment with GitHub Actions.
+1. Go to **Settings → Secrets and variables → Actions → Variables tab**
+2. Click **New repository variable**
+3. Add:
+   - **Name**: `AWS_RESOURCE_PREFIX`
+   - **Value**: Your AWS resource prefix (e.g., `kaapi`)
 
-## Environment Variables
+### Step 3: AWS Authentication Setup
 
-You need to set some environment variables first.
+The workflows use **AWS OIDC authentication**, which is more secure than storing AWS access keys:
+- No long-lived credentials stored in GitHub
+- AWS IAM role assumes identity based on GitHub's OIDC token
+- Permissions are scoped to specific actions
 
-Set the `ENVIRONMENT`, by default `local` (for development), but when deploying to a server you would put something like `staging` or `production`:
+The IAM role ARN is configured in workflow files:
 
-```bash
-export ENVIRONMENT=production
-```
-
-Set the `DOMAIN`, by default `localhost` (for development), but when deploying you would use your own domain, for example:
-
-```bash
-export DOMAIN=fastapi-project.example.com
+```yaml
+role-to-assume: arn:aws:iam::{YOUR_AWS_ACCOUNT_ID}:role/github-action-role
+aws-region: {YOUR_AWS_REGION}
 ```
 
-You can set several variables, like:
+**Note**: Replace `{YOUR_AWS_ACCOUNT_ID}` with your AWS account ID and `{YOUR_AWS_REGION}` with your chosen region (e.g., `ap-south-1`, `us-east-1`).
 
-* `PROJECT_NAME`: The name of the project, used in the API for the docs and emails.
-* `STACK_NAME`: The name of the stack used for Docker Compose labels and project name, this should be different for `staging`, `production`, etc. You could use the same domain replacing dots with dashes, e.g. `fastapi-project-example-com` and `staging-fastapi-project-example-com`.
-* `BACKEND_CORS_ORIGINS`: A list of allowed CORS origins separated by commas.
-* `SECRET_KEY`: The secret key for the FastAPI project, used to sign tokens.
-* `FIRST_SUPERUSER`: The email of the first superuser, this superuser will be the one that can create new users.
-* `FIRST_SUPERUSER_PASSWORD`: The password of the first superuser.
-* `SMTP_HOST`: The SMTP server host to send emails, this would come from your email provider (E.g. Mailgun, Sparkpost, Sendgrid, etc).
-* `SMTP_USER`: The SMTP server user to send emails.
-* `SMTP_PASSWORD`: The SMTP server password to send emails.
-* `EMAILS_FROM_EMAIL`: The email account to send emails from.
-* `POSTGRES_SERVER`: The hostname of the PostgreSQL server. You can leave the default of `db`, provided by the same Docker Compose. You normally wouldn't need to change this unless you are using a third-party provider.
-* `POSTGRES_PORT`: The port of the PostgreSQL server. You can leave the default. You normally wouldn't need to change this unless you are using a third-party provider.
-* `POSTGRES_PASSWORD`: The Postgres password.
-* `POSTGRES_USER`: The Postgres user, you can leave the default.
-* `POSTGRES_DB`: The database name to use for this application. You can leave the default of `app`.
-* `SENTRY_DSN`: The DSN for Sentry, if you are using it.
+## Environment Variables in AWS ECS
 
-## GitHub Actions Environment Variables
+Application configuration is managed through environment variables set in **ECS Task Definitions**. These are injected into containers at runtime.
 
-There are some environment variables only used by GitHub Actions that you can configure:
+### Configuring Environment Variables
 
-* `LATEST_CHANGES`: Used by the GitHub Action [latest-changes](https://github.com/tiangolo/latest-changes) to automatically add release notes based on the PRs merged. It's a personal access token, read the docs for details.
-* `SMOKESHOW_AUTH_KEY`: Used to handle and publish the code coverage using [Smokeshow](https://github.com/samuelcolvin/smokeshow), follow their instructions to create a (free) Smokeshow key.
+Environment variables in ECS Task Definitions include database credentials, AWS credentials, API keys, and service endpoints. Refer to `.env.example` in the repository for a complete list of required and optional variables.
 
-### Generate secret keys
+Key categories:
+- **Authentication & Security**: JWT keys, admin credentials
+- **Database**: PostgreSQL connection details
+- **AWS Services**: S3 access credentials
+- **Background Tasks**: RabbitMQ and Redis endpoints
+- **Optional**: OpenAI API key, Sentry DSN
 
-Some environment variables in the `.env` file have a default value of `changethis`.
+### Generate Secure Keys
 
-You have to change them with a secret key, to generate secret keys you can run the following command:
+Use Python to generate cryptographically secure keys:
 
 ```bash
 python -c "import secrets; print(secrets.token_urlsafe(32))"
 ```
 
-Copy the content and use that as password / secret key. And run that again to generate another secure key.
-
-### Deploy with Docker Compose
-
-With the environment variables in place, you can deploy with Docker Compose:
-
-```bash
-docker compose -f docker-compose.yml up -d
-```
-
-For production you wouldn't want to have the overrides in `docker-compose.override.yml`, that's why we explicitly specify `docker-compose.yml` as the file to use.
-
-## Continuous Deployment (CD)
-
-You can use GitHub Actions to deploy your project automatically. 😎
+Run this multiple times to generate different keys for `SECRET_KEY`, passwords, etc.
 
-You can have multiple environment deployments.
+## Database Migrations
 
-There are already two environments configured, `staging` and `production`. 🚀
+Database schema changes must be applied before deploying new application versions. This ensures the database structure matches what the code expects.
 
-### Install GitHub Actions Runner
+### Using ECS Run Task (Recommended for Production)
 
-* On your remote server, create a user for your GitHub Actions:
+Run migrations as a one-time ECS task:
 
 ```bash
-sudo adduser github
+aws ecs run-task \
+  --cluster {prefix}-cluster \
+  --task-definition {migration-task-def} \
+  --region {YOUR_AWS_REGION}
 ```
 
-* Add Docker permissions to the `github` user:
+This runs the migration in the same environment as your application, ensuring consistency.
 
-```bash
-sudo usermod -aG docker github
-```
+### Local Migration (Development/Testing)
 
-* Temporarily switch to the `github` user:
+For testing migrations locally:
 
 ```bash
-sudo su - github
+cd backend
+uv run alembic upgrade head
 ```
 
-* Go to the `github` user's home directory:
-
-```bash
-cd
-```
+**Important**: Always test migrations in staging before applying to production.
 
-* [Install a GitHub Action self-hosted runner following the official guide](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners#adding-a-self-hosted-runner-to-a-repository).
+## Monitoring & Observability
 
-* When asked about labels, add a label for the environment, e.g. `production`. You can also add labels later.
-
-After installing, the guide would tell you to run a command to start the runner. Nevertheless, it would stop once you terminate that process or if your local connection to your server is lost.
-
-To make sure it runs on startup and continues running, you can install it as a service. To do that, exit the `github` user and go back to the `root` user:
+### AWS CloudWatch
 
+**Logs**: View application logs from ECS tasks
 ```bash
-exit
+aws logs tail /ecs/{cluster}/{service} --follow
 ```
 
-After you do it, you will be on the previous user again. And you will be on the previous directory, belonging to that user.
+**Metrics**: Monitor CPU, memory, request count, error rates
 
-Before being able to go the `github` user directory, you need to become the `root` user (you might already be):
+### ECS Console
 
-```bash
-sudo su
-```
+- View running tasks and their health status
+- Check deployment status and history
+- Monitor service events and errors
 
-* As the `root` user, go to the `actions-runner` directory inside of the `github` user's home directory:
+### Health Checks
 
-```bash
-cd /home/github/actions-runner
-```
+ECS performs health checks on the `/api/v1/utils/health/` endpoint. If this fails, tasks are replaced automatically.
 
-* Install the self-hosted runner as a service with the user `github`:
+## Rollback Procedures
 
-```bash
-./svc.sh install github
-```
+If a deployment introduces issues, rollback to a previous stable version.
 
-* Start the service:
+### List Previous Versions
 
 ```bash
-./svc.sh start
+aws ecs list-task-definitions --family-prefix {prefix}
 ```
 
-* Check the status of the service:
+### Rollback to Previous Version
 
 ```bash
-./svc.sh status
+aws ecs update-service \
+  --cluster {prefix}-cluster \
+  --service {prefix}-service \
+  --task-definition {previous-task-def-arn} \
+  --region {YOUR_AWS_REGION}
 ```
 
-You can read more about it in the official guide: [Configuring the self-hosted runner application as a service](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/configuring-the-self-hosted-runner-application-as-a-service).
-
-### Set Secrets
-
-On your repository, configure secrets for the environment variables you need, the same ones described above, including `SECRET_KEY`, etc. Follow the [official GitHub guide for setting repository secrets](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository).
-
-The current Github Actions workflows expect these secrets:
-
-* `DOMAIN_PRODUCTION`
-* `DOMAIN_STAGING`
-* `STACK_NAME_PRODUCTION`
-* `STACK_NAME_STAGING`
-* `EMAILS_FROM_EMAIL`
-* `FIRST_SUPERUSER`
-* `FIRST_SUPERUSER_PASSWORD`
-* `POSTGRES_PASSWORD`
-* `SECRET_KEY`
-* `LATEST_CHANGES`
-* `SMOKESHOW_AUTH_KEY`
-
-## GitHub Action Deployment Workflows
-
-There are GitHub Action workflows in the `.github/workflows` directory already configured for deploying to the environments (GitHub Actions runners with the labels):
-
-* `staging`: after pushing (or merging) to the branch `master`.
-* `production`: after publishing a release.
-
-If you need to add extra environments you could use those as a starting point.
-
-## URLs
-
-Replace `fastapi-project.example.com` with your domain.
-
-### Main Traefik Dashboard
-
-Traefik UI: `https://traefik.fastapi-project.example.com`
-
-### Production
-
-Frontend: `https://dashboard.fastapi-project.example.com`
-
-Backend API docs: `https://api.fastapi-project.example.com/docs`
-
-Backend API base URL: `https://api.fastapi-project.example.com`
-
-Adminer: `https://adminer.fastapi-project.example.com`
-
-### Staging
-
-Frontend: `https://dashboard.staging.fastapi-project.example.com`
-
-Backend API docs: `https://api.staging.fastapi-project.example.com/docs`
-
-Backend API base URL: `https://api.staging.fastapi-project.example.com`
+ECS will perform a rolling update back to the specified task definition.
 
-Adminer: `https://adminer.staging.fastapi-project.example.com`
+**Tip**: Keep track of stable task definition ARNs for quick rollbacks.
diff --git a/development.md b/development.md
index f927352a3..200508125 100644
--- a/development.md
+++ b/development.md
@@ -1,4 +1,4 @@
-# AI Platform - Development
+# Kaapi - Development
 
 ## Docker Compose
 
@@ -10,15 +10,17 @@ docker compose watch
 
 * Now you can open your browser and interact with these URLs:
 
-Frontend, built with Docker, with routes handled based on the path: http://localhost:5173
+Backend, JSON-based web API based on OpenAPI: <http://localhost:8000>
 
-Backend, JSON based web API based on OpenAPI: http://localhost:8000
+Automatic interactive documentation with Swagger UI (from the OpenAPI backend): <http://localhost:8000/docs>
 
-Automatic interactive documentation with Swagger UI (from the OpenAPI backend): http://localhost:8000/docs
+Alternative interactive documentation (ReDoc): <http://localhost:8000/redoc>
 
-Adminer, database web administration: http://localhost:8080
+Adminer, database web administration: <http://localhost:8080>
 
-Traefik UI, to see how the routes are being handled by the proxy: http://localhost:8090
+RabbitMQ Management UI: <http://localhost:15672>
+
+Celery Flower (task monitoring): <http://localhost:5555>
 
 **Note**: The first time you start your stack, it might take a minute for it to be ready. While the backend waits for the database to be ready and configures everything. You can check the logs to monitor it.
 
@@ -38,75 +40,102 @@ docker compose logs backend
 
 The Docker Compose files are configured so that each of the services is available in a different port in `localhost`.
 
-For the backend and frontend, they use the same port that would be used by their local development server, so, the backend is at `http://localhost:8000` and the frontend at `http://localhost:5173`.
+You can stop the `backend` Docker Compose service and run the local development server instead:
 
-This way, you could turn off a Docker Compose service and start its local development service, and everything would keep working, because it all uses the same ports.
+```bash
+docker compose stop backend
+```
 
-For example, you can stop that `frontend` service in the Docker Compose, in another terminal, run:
+And then start the local development server for the backend:
 
 ```bash
-docker compose stop frontend
+cd backend
+fastapi run --reload app/main.py
 ```
 
-And then start the local frontend development server:
+This way the backend runs on the same port (<http://localhost:8000>) whether it's in Docker or running locally.
+
+### Running Completely Without Docker
+
+If you want to run everything locally without Docker, you'll need to set up RabbitMQ, Redis, Celery, and optionally Celery Flower manually.
+
+#### 1. Install and Start RabbitMQ & Redis
+
+**macOS (using Homebrew):**
 
 ```bash
-cd frontend
-npm run dev
+brew install rabbitmq redis
+
+brew services start rabbitmq
+brew services start redis
 ```
 
-Or you could stop the `backend` Docker Compose service:
+**Ubuntu / Debian:**
 
 ```bash
-docker compose stop backend
+sudo apt update
+sudo apt install rabbitmq-server redis-server
+
+sudo systemctl enable --now rabbitmq-server
+sudo systemctl enable --now redis-server
 ```
 
-And then you can run the local development server for the backend:
+**Verify services are running:**
+
+- RabbitMQ Management UI: <http://localhost:15672> (default credentials: `guest`/`guest`)
+- Redis: `redis-cli ping` (should return `PONG`)
+
+#### 2. Start the Backend Server
+
+In your first terminal:
 
 ```bash
 cd backend
-fastapi dev app/main.py
+fastapi run --reload app/main.py
 ```
 
-## Docker Compose in `localhost.tiangolo.com`
-
-When you start the Docker Compose stack, it uses `localhost` by default, with different ports for each service (backend, frontend, adminer, etc).
+The backend will be available at <http://localhost:8000>
 
-When you deploy it to production (or staging), it will deploy each service in a different subdomain, like `api.example.com` for the backend and `dashboard.example.com` for the frontend.
+#### 3. Start Celery Worker
 
-In the guide about [deployment](deployment.md) you can read about Traefik, the configured proxy. That's the component in charge of transmitting traffic to each service based on the subdomain.
+In a second terminal, start the Celery worker:
 
-If you want to test that it's all working locally, you can edit the local `.env` file, and change:
-
-```dotenv
-DOMAIN=localhost.tiangolo.com
+```bash
+cd backend
+uv run celery -A app.celery.celery_app worker --loglevel=info
 ```
 
-That will be used by the Docker Compose files to configure the base domain for the services.
+Leave this process running. This handles background tasks like document processing and LLM job execution.
 
-Traefik will use this to transmit traffic at `api.localhost.tiangolo.com` to the backend, and traffic at `dashboard.localhost.tiangolo.com` to the frontend.
+#### 4. (Optional) Start Celery Flower for Task Monitoring
 
-The domain `localhost.tiangolo.com` is a special domain that is configured (with all its subdomains) to point to `127.0.0.1`. This way you can use that for your local development.
+Flower provides a web UI to monitor Celery tasks and workers.
 
-After you update it, run again:
+**Start Flower in a fourth terminal:**
 
 ```bash
-docker compose watch
+cd backend
+uv run celery -A app.celery.celery_app flower --port=5555
 ```
 
-When deploying, for example in production, the main Traefik is configured outside of the Docker Compose files. For local development, there's an included Traefik in `docker-compose.override.yml`, just to let you test that the domains work as expected, for example with `api.localhost.tiangolo.com` and `dashboard.localhost.tiangolo.com`.
+Flower will be available at: <http://localhost:5555>
 
-## Docker Compose files and env vars
+> **Note:** If you start Flower before running any Celery workers, you may see warnings like:
+> ```text
+> WARNING - flower.inspector - Inspect method ... failed
+> ```
+> This just means there are no active workers yet. Once you start a Celery worker (step 3),
+> Flower will be able to inspect it and the warnings will stop.
 
-There is a main `docker-compose.yml` file with all the configurations that apply to the whole stack, it is used automatically by `docker compose`.
+---
 
-And there's also a `docker-compose.override.yml` with overrides for development, for example to mount the source code as a volume. It is used automatically by `docker compose` to apply overrides on top of `docker-compose.yml`.
+## Docker Compose files and env vars
 
-These Docker Compose files use the `.env` file containing configurations to be injected as environment variables in the containers.
+The `docker-compose.yml` file contains all the configurations for the stack, including services like PostgreSQL, Redis, RabbitMQ, backend, Celery workers, and Adminer.
 
-They also use some additional configurations taken from environment variables set in the scripts before calling the `docker compose` command.
+The Docker Compose file uses the `.env` file containing configurations to be injected as environment variables in the containers.
 
-After changing variables, make sure you restart the stack:
+After changing environment variables, make sure you restart the stack:
 
 ```bash
 docker compose watch
@@ -166,42 +195,18 @@ eslint...................................................................Passed
 prettier.................................................................Passed
 ```
 
-## URLs
-
-The production or staging URLs would use these same paths, but with your own domain.
-
-### Development URLs
-
-Development URLs, for local development.
-
-Frontend: http://localhost:5173
-
-Backend: http://localhost:8000
-
-Automatic Interactive Docs (Swagger UI): http://localhost:8000/docs
-
-Automatic Alternative Docs (ReDoc): http://localhost:8000/redoc
-
-Adminer: http://localhost:8080
-
-Traefik UI: http://localhost:8090
-
-MailCatcher: http://localhost:1080
-
-### Development URLs with `localhost.tiangolo.com` Configured
-
-Development URLs, for local development.
+## Development URLs
 
-Frontend: http://dashboard.localhost.tiangolo.com
+All services are available on localhost with different ports:
 
-Backend: http://api.localhost.tiangolo.com
+**Backend**: <http://localhost:8000>
 
-Automatic Interactive Docs (Swagger UI): http://api.localhost.tiangolo.com/docs
+**Swagger UI** (Interactive API Docs): <http://localhost:8000/docs>
 
-Automatic Alternative Docs (ReDoc): http://api.localhost.tiangolo.com/redoc
+**ReDoc** (Alternative API Docs): <http://localhost:8000/redoc>
 
-Adminer: http://localhost.tiangolo.com:8080
+**Adminer** (Database Management): <http://localhost:8080>
 
-Traefik UI: http://localhost.tiangolo.com:8090
+**RabbitMQ Management**: <http://localhost:15672> (username: guest, password: guest)
 
-MailCatcher: http://localhost.tiangolo.com:1080
+**Celery Flower** (Task Monitoring): <http://localhost:5555>
