Autoalojamiento

Docker (recomendado)

git clone https://github.com/basb7/flagward.git
cd flagward

# Modo desarrollo: hot-reload, debug activado, runserver (reinicio automático en cambios)
docker compose -f compose.dev.yml up

# Modo producción: Gunicorn con 4 workers, debug desactivado, optimizado
docker compose up

Servicios:

Archivos Compose

docker compose -f compose.dev.yml up      # desarrollo, hot-reload
docker compose -f compose.dev.yml up -d   # desarrollo, en segundo plano
docker compose up                          # producción
docker compose up -d                       # producción, en segundo plano
docker compose down                        # detiene todos los servicios
docker compose down -v                     # detiene y elimina los volúmenes
docker compose logs -f backend             # ver logs del backend
docker compose build --no-cache            # reconstruir las imágenes

Configuración

Copia .env.example a .env y configúralo:

cp .env.example .env

El archivo se lee al arrancar, tanto en desarrollo como en producción, y se resuelve junto a manage.py en lugar de desde el directorio de trabajo. Los valores ya presentes en el entorno prevalecen sobre el archivo — un contenedor que establece DB_HOST mediante compose lo conserva aunque un .env haya llegado a la imagen.

Algunos de los ajustes que conviene conocer antes de desplegar:

El correo (EMAIL_HOST y afines) es completamente opcional; una instancia autoalojada sigue funcionando sin nada de eso configurado. Con EMAIL_HOST sin establecer y DEBUG=True, el correo saliente se imprime en la terminal en lugar de enviarse, así que el flujo de restablecimiento de contraseña se puede probar sin un servidor de correo. Consulta el README de flagward para la referencia completa de variables.

Despliegue en producción

1. Prepara tu servidor (AWS, GCP, DigitalOcean, etc.).
2. Clona el repositorio y ejecuta cp .env.example .env, luego edítalo con tus valores de producción.
3. docker compose up -d.
4. Verifica con docker compose ps y docker compose logs backend.
5. Pon Nginx o Traefik delante con un certificado TLS (Let's Encrypt).

Desarrollo local (sin Docker)

Requisitos previos: Python 3.14+, Node.js 20+.

# Backend
python -m venv .venv
source .venv/bin/activate
pip install -r requirements/base.txt
pip install -r requirements/dev.txt
python manage.py migrate
python manage.py createsuperuser
python manage.py runserver

# Frontend (en otra terminal)
cd frontend
npm install
npm run dev

Creando tu primera flag

1. Regístrate en http://localhost:3000/register — usuario, correo, contraseña. Este no es tu superusuario: el superusuario administra el despliegue a través de Django admin y no tiene membresía en ningún lugar, así que el panel no le muestra nada. Quien se registra se convierte en el ADMIN de las organizaciones que crea.
2. Crea tu organización — el panel pide una en cuanto llegas sin ninguna.
3. Crea un proyecto — nav → New project. Sin clave que inventar: el servidor la deriva a partir del nombre.
4. Crea un entorno — Environments → New Environment. La clave de API se genera automáticamente y se puede copiar desde la tabla.
5. Crea una feature flag — Flags → New Flag, elige el entorno, dale una clave y un nombre.
6. Actívala — cambia el interruptor en la columna Status.
7. Añade reglas y condiciones (opcional) — menú de la fila → Rules → New Rule, y luego una condición como country Equals US.
8. Míralo funcionar — Monitoring muestra qué SDKs están conectados. No mostrará evaluaciones de un cliente que evalúa localmente, que es lo que hacen los SDKs de JavaScript — esos nunca llegan al servidor.

Matar una flag durante un incidente

No recurras al interruptor propio de la flag — eso edita su diseño y pierde el estado en el que estaba. En su lugar, ve a Monitoring → Overrides → New override, elige la flag, selecciona Disabled (kill switch), y escribe el motivo. La flag se fuerza a apagada de inmediato, para todos, ignorando sus reglas de segmentación. Pulsa Lift cuando termine el incidente y la flag vuelve exactamente a la configuración que tenía.