Documentación

Agrega secretos en Proyecto → Secrets (o fluentops secrets add KEY=VALUE). Se cifran en reposo y se inyectan tanto en tiempo de build como en tu backend en runtime, así que código como process.env.OPENAI_API_KEY (u os.environ) simplemente funciona.

• Prefija una variable con VITE_ para exponerla al bundle del navegador (seguro para claves/URLs públicas).
• Mantén las claves de servicio y secretas sin prefijo — se quedan del lado del servidor y llegan a tu backend en runtime.
• Conectar un servicio lista las variables exactas para Supabase, OpenAI, Stripe, Firebase y más.

En Proyecto → Domains, agrega tu dominio (p. ej. www.miempresa.com). FluentOps emite un certificado gratis y muestra los registros DNS exactos que hay que agregar, en dos pasos:

1. Verifica la propiedad — agrega el registro CNAME de validación (una vez; las renovaciones lo reutilizan).
2. Apunta tu dominio — agrega el registro de ruteo en tu proveedor DNS.

Para un dominio raíz/apex: si tu DNS lo soporta (Cloudflare, Route 53…) agregas el registro en @ directamente. Si tu registrador no puede (p. ej. Namecheap), conecta www y agrega una redirección 301 sin enmascarar desde la raíz — la interfaz lo detecta y muestra los registros correctos. El HTTPS se aprovisiona y renueva automáticamente en cuanto el DNS resuelve.

FluentOps Forms convierte un simple <form> de tu sitio estático en captura de leads real — sin backend, sin código. Los envíos llegan a la bandeja de tu proyecto y te avisan por correo al instante. Es gratis (100 envíos/mes por cuenta). Ver la página de Forms.

1 · Actívalo

En tu proyecto, abre la pestaña Grow y haz clic en Enable forms. Obtienes una URL de endpoint única para ese proyecto.

2 · Vuelve a desplegar

Activarlo no cambia el sitio que ya está publicado. En tu próximo despliegue conectamos cada <form> de tu HTML que no tenga destino propio (sin action, con #, un .php, o un formulario de Netlify). Los buscadores, los logins y los formularios que apuntaste a otro servicio no se tocan. El panel te dice qué formularios conectó.

Si escribes el formulario tú

<form action="https://api.fluentops.org/forms/<token>" method="POST">
  <input name="email" />
  <textarea name="message"></textarea>
  <input type="text" name="_gotcha" style="display:none" tabindex="-1" />
  <button>Send</button>
</form>

Cualquier nombre de campo funciona — todos llegan a tu bandeja. El campo oculto _gotcha es una trampa (honeypot): el envío de un bot que lo llena se guarda marcado como spam y no te manda correo.

React, Vite, Bolt, Lovable (apps de JavaScript)

En una app de JavaScript el formulario lo dibuja el código, así que un despliegue no puede conectarlo. Envíalo con fetch — sirve JSON o form data — o pega en tu herramienta de IA el prompt que te da el panel:

const res = await fetch('https://api.fluentops.org/forms/<token>', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ ...form, 'form-name': 'contact' }),
})
if (res.ok) { /* show your thank-you message */ }

Campos opcionales

• _redirect (o _next) — envía al visitante a una página de gracias tras enviar; sin él recibe una pequeña respuesta JSON.
• form-name (o _form) — etiqueta los envíos cuando un proyecto tiene más de un formulario.

Free incluye 100 envíos/mes en todos tus sitios, guardados 30 días. Pro lo sube a 1,000/mes con exportar CSV y retención ilimitada. Al pasar el límite, los leads se siguen capturando — nunca perdemos uno.

FluentOps corre un backend real para tu app — un proceso real en un contenedor, no una función serverless. Mantiene estado en memoria, sostiene conexiones WebSocket y se conecta a tu base de datos normalmente.

Cero config — detectamos tu stack

No escribes un Dockerfile. Igual que con el front-end, leemos los archivos de tu proyecto y construimos la imagen por ti. Despliega de la misma forma (CLI, arrastrar y soltar, o Git); si encontramos un servidor, lo desplegamos junto a tu front-end en un solo paso.

Dónde vive

Desplegado solo, tu backend responde en todas las rutas de la URL de tu proyecto — las que escribiste, donde las hayas montado. Nada más compite por /, así que no te lo quitamos:

https://your-project.fluentops.org/users

/api/* sigue funcionando en ambos casos, así que una URL que ya tenías cableada no se rompe. Los secretos de tu proyecto se inyectan como variables de entorno en runtime, así process.env / os.environ funciona.

Front + back en un proyecto (monorepos)

¿Tienes tu front-end y backend en un repo (digamos web/ y api/)? Despliégalo tal cual — escaneamos tus carpetas, encontramos ambos y los desplegamos juntos: el front-end en /, la API en /api/*. También puedes desplegar solo uno. Si encontramos más de un front-end o más de un backend, te preguntamos cuál desplegar.

Apps que renderizan sus propias páginas

Si tu app renderiza sus páginas en el servidor — Next.js SSR, Nuxt, SvelteKit, Astro, Remix, Django, Rails, o una app Express/Flask con plantillas — despliégala tal cual. La detectamos, la construimos, y tu app es dueña de todas las rutas en /, no solo de /api/*. Sin output: "export", sin partirla en dos, sin cambios en tu código.

Vale conocer el trade-off: un front-end estático se sirve desde el CDN y sigue en pie aunque un backend Free esté dormido, mientras que una app server-rendered construye cada página en tu contenedor. Si tu sitio es contenido que no cambia por visitante, un build estático sigue siendo más rápido y barato — pero esa es tu decisión, no un límite que te imponemos.

Modos de ejecución

Cada backend es un artefacto con un modo de ejecución que eliges en la página del proyecto (junto a Secrets). Cámbialo cuando quieras — sin re-desplegar.

• Always on — un servicio que sigue escuchando (una API, un servidor web). En Free se duerme tras unos minutos inactivo y despierta en la primera petición (un cold start de ~1–3s); en Pro nunca se duerme.
• On demand — un job que corre cuando se dispara y se detiene. Te damos una URL de activación privada (POST) y un botón Run now; los logs y el código de salida de cada corrida se guardan en el historial.
• On a schedule — el mismo job en un horario cron (UTC). Free corre a lo mucho una vez al día; Pro permite horarios por minuto.

Los minutos de ejecución de los jobs on-demand y programados se miden contra la cuota mensual de tu plan; cuando la alcanzas, los jobs se pausan hasta el mes siguiente — nunca se te cobra excedente.

FluentOps hospeda tu app, no tu base de datos — el mismo modelo que Vercel. Usa un proveedor gestionado y conéctate a él desde tu backend con un secreto:

• Supabase / Neon — Postgres
• PlanetScale — MySQL
• Upstash — Redis
• Cualquier host — pon la cadena de conexión como secreto (p. ej. DATABASE_URL)

La sección de Secrets del panel tiene recetas de copiar y pegar para los más comunes, con los nombres exactos de variable que cada uno espera.

Comandos

Modo agente y JSON

--json emite salida legible por máquina y --yes nunca pregunta — ambos se activan solos cuando la salida no es una terminal, así agentes y CI funcionan sin flags.

fluentops deploy --json --yes
# {"status":"success","project_slug":"my-app",
#  "url":"https://my-app.fluentops.org",
#  "warnings":[{"kind":"missing_env","items":["VITE_SUPABASE_URL"],
#    "fix":"fluentops secrets add VITE_SUPABASE_URL=<value> && fluentops deploy"}]}

Un deploy que no queda en línea sale con código distinto de cero, "status":"error" y un code estable: needs_selection (con las options encontradas — vuelve a correr con --front/--back), build_failed (con error y las últimas líneas del log en log_tail) o unsupported_stack. Todo lo que un agente necesita para corregir y reintentar, sin un segundo comando.

Ignorar archivos

node_modules, .git, dist, build, out y .fluentops siempre se omiten. Agrega un .fluentopsignore (sintaxis de gitignore) para excluir más.

Front-end (hosting estático)

• React (CRA o cualquier bundler con un script de build)
• Vite (incluido React + Vite)
• Next.js export estático (output: "export")
• HTML estático / CSS / JS

Apps que renderizan sus páginas (server-side)

Se despliegan tal cual: la app es dueña de todas las rutas en /, y la construimos como su framework espera. Sin output: "export", sin cambios de código.

• Next.js (SSR / App Router — rutas dinámicas, middleware y route handlers incluidos)
• Nuxt, SvelteKit, Astro (modo servidor), Remix
• Django — manage.py y tu módulo de settings; corremos collectstatic por ti
• Rails con vistas, y apps Express / Flask / FastAPI que renderizan plantillas (EJS, Pug, Jinja, ERB…)

Backend (auto-detectado, sin Dockerfile)

• Node — Express, Fastify, Hono, Koa, NestJS, Elysia (o cualquier servidor con un script start)
• Python — FastAPI, Flask, o un script/worker plano (job.py, main.py…) corrido como job
• Go — cualquier módulo con un paquete main
• Ruby — Rails, o apps Rack (Sinatra/Roda) con un config.ru
• Jobs y cron — un script que corre y termina es un job: por defecto queda On demand (se dispara por URL/CLI) y puede cambiarse a On a schedule. Sin servidor, sin Dockerfile.

Cualquier otro lenguaje

FluentOps construye tu app desde el stack que detecta — no ejecuta un contenedor subido, así que un Dockerfile en tu proyecto se ignora (te avisamos cuando omitimos uno). Los stacks que aún no construimos — Rust, Java, PHP, Deno y otros — no están soportados por ahora; dinos qué necesitas y lo priorizamos.

Si no podemos saber cómo iniciar tu backend, el build falla con un mensaje claro (p. ej. "agrega un script start a package.json").

¿Sigues atorado? Usa Enviar Feedback en el panel — incluye tu WhatsApp y te contactamos.