Cómo crear un panel de administración con asistente IA en Next.js

Al terminar esta guía tendrás un panel de administración interno con un asistente de IA funcionando en tu ordenador y listo para pasar a un servidor. Es un dashboard en Next.js con su propia API detrás, y lo construyes a partir de la plantilla Admin Dashboard Template 2 de Aniq UI en lugar de empezar con una carpeta vacía.

Los pasos sirven para un panel de administración SaaS, para el back office de una empresa pequeña o para cualquier herramienta interna donde un equipo necesite listas, roles y una forma de hacer preguntas sobre sus propios datos. Para hacerlo concreto, seguimos a una empresa inventada durante todo el trabajo, desde la primera descarga hasta una dirección en línea, y nos detenemos en cada punto donde algo suele salir mal.

Antes de empezar: decisiones que tomar

La mayor parte del dolor de cabeza en una herramienta interna viene de decisiones tomadas tarde. Resuelve estas seis antes de abrir una terminal y el resto de la guía irá más rápido.

• ¿Quién inicia sesión y qué puede hacer cada persona? Escribe primero la lista de roles en papel. La plantilla trae cinco (Super Admin, Admin, Manager, Editor, Viewer) y puedes remodelarlos, pero es más fácil hacerlo con un plan.
• ¿Cuáles son tus registros? La plantilla incluye usuarios, proyectos, tareas y ajustes de la aplicación. Si tu negocio gira en torno a otra cosa, como pedidos o tickets, decide ahora si vas a renombrar lo que existe o a añadir un módulo nuevo a la API.
• ¿Qué idiomas? Vienen inglés y árabe. Un tercer idioma es posible, pero da más trabajo, así que sabe antes de empezar si lo necesitas.
• ¿Quién paga la IA? O bien la empresa guarda una clave de proveedor en el servidor, o bien cada persona trae la suya. La elección cambia tu factura y tu política de privacidad, y el paso 8 cubre ambas.
• ¿Dónde se ejecutará? En un servidor pequeño con Docker, o en Vercel para el dashboard con la API en un host Docker. Elige la forma pronto para configurar las direcciones correctas una sola vez.
• ¿Qué base de datos? SQLite es la opción por defecto y no necesita configuración. MySQL es un cambio de configuración. Un host sin disco persistente es el motivo habitual para elegir MySQL.

El encargo

Larkspur Software es una agencia pequeña que crea aplicaciones web para otras empresas. La oficina necesita un solo lugar para llevar su trabajo. Esto es lo que pide el equipo:

• Un inicio de sesión para el personal, con distintos niveles de acceso: el dueño lo ve todo, los desarrolladores editan proyectos y los colaboradores externos solo leen.
• Una lista de todos los proyectos de clientes, con su estado, su entorno (staging o producción) y su versión actual.
• Una lista de cuentas de clientes, con una forma rápida de encontrar a quienes nunca verificaron su correo.
• Un asistente que responda preguntas sencillas como «¿qué proyectos están bloqueados?» y muestre la respuesta como tabla o gráfico.
• Inglés y árabe, porque dos equipos de clientes leen árabe.
• Una primera prueba en un portátil y después un servidor pequeño con el dominio propio de la agencia.
• Control sobre quién puede usar el asistente, ya que puede modificar registros y el proveedor de IA cobra por uso.

Cómo cubre la plantilla el encargo

Necesidad	Dónde está	Qué usas
Personal con distinto acceso	Dashboard y API	Pantallas Admin Management y Admin Roles; permisos con nombres como projects.edit
Seguimiento de proyectos de clientes	Dashboard y API	Pantalla Projects con estado, entorno, versión y nombre en inglés y árabe
Cuentas de clientes	Dashboard y API	Pantallas Users y Deleted users, filtros, acciones de verificar y restaurar
Preguntas en lenguaje natural	Dashboard y API	Pantalla AI Assistant, con una clave de proveedor que pones tú
Inglés y árabe	Dashboard	Direcciones /en y /ar, archivos de mensajes en messages/
Portátil y después un servidor	Docker y configuración	Docker Compose, archivos .env, un servidor web por delante
Control sobre el asistente	API	El permiso ai_chat.use en un rol

Plantilla, desde cero o un constructor alojado

Hay tres formas honestas de conseguir un panel de administración con asistente de IA, y cada una encaja con un equipo distinto.

Desde cero. Obtienes exactamente la estructura que quieres y nada más. También tienes que construir el inicio de sesión, los roles con actualización en vivo, las listas con filtros, una interfaz de chat que muestre tablas y gráficos, y la API que hay detrás. Esto conviene a equipos con un producto poco habitual y mucho tiempo de ingeniería. Para todos los demás significa pasar mucho tiempo en pantallas que todo panel de administración necesita.

Un constructor alojado. Un servicio low-code o de herramientas internas te da una pantalla funcional enseguida y se ocupa del alojamiento. A cambio trabajas dentro de su conjunto de componentes y de su modelo de precios, y irte después suele significar reconstruir. Comprueba cuánto cobra por usuario, qué puedes exportar y si admite diseños de derecha a izquierda antes de comprometerte.

Una plantilla con código fuente. Empiezas con pantallas terminadas, una API que funciona y un asistente, y el código es tuyo. Pagas una vez por la plantilla, la alojas tú y cambias lo que quieras. El coste es que debes sentirte cómodo con Next.js y, más adelante, con NestJS si amplías la API. La licencia no permite publicar ni revender el código fuente, pero sí cubre proyectos ilimitados, incluidos los de clientes.

Larkspur tiene desarrolladores en plantilla y quiere guardar los datos de sus clientes en su propio servidor, así que elige la plantilla. Si nadie en tu equipo programa, un constructor alojado es la opción más realista.

Un plan de lanzamiento de ejemplo por semanas

Este es un calendario de muestra para Larkspur, no una referencia. Tu ritmo será distinto.

• Semana 1, ponerlo en marcha. Descarga el ZIP, arráncalo con Docker, recorre todas las pantallas y prueba las dos cuentas de ejemplo. Decide las seis preguntas de arriba.
• Semana 2, hacerlo suyo. Ponle la marca, reconstruye los roles, crea las cuentas reales del personal y borra los administradores de ejemplo.
• Semana 3, cargar el trabajo. Introduce los proyectos y las cuentas de clientes reales, añade las claves de proveedor y deja que dos o tres personas usen el asistente con preguntas reales.
• Semana 4, reforzar y publicar. Define los valores de entorno de producción, despliega en el servidor, comprueba la dirección de salud y repasa la lista de verificación de lanzamiento que aparece cerca del final de este artículo.

Paso a paso

1. Elige el paquete

La plantilla viene en tres paquetes. El paquete Full Stack contiene el dashboard y la API de NestJS. El paquete Admin Dashboard es solo el dashboard, que funciona con un pequeño servidor simulado integrado y guarda los registros de ejemplo en tu navegador. El paquete Backend API es solo la API.

Larkspur quiere datos reales y un asistente real, así que elige Full Stack. Si solo quieres diseñar pantallas primero, el paquete Admin Dashboard basta, y puedes conectarlo a una API más tarde. Si ya tienes un front end y solo necesitas el servidor, el paquete Backend API te da las rutas, la lógica de roles y las herramientas del asistente.

Comprueba: tras la descarga, tu cuenta debe mostrar un ZIP con el nombre del paquete que compraste. Lo que suele salir mal: comprar el paquete del dashboard y esperar que incluya una API. El dashboard solo no puede guardar nada fuera del navegador.

2. Ejecútalo en local con Docker

Instala Docker Desktop (o Docker Engine en Linux) y nada más. Después sigue estos subpasos.

2a. Descarga. Abre My templates en tu cuenta de Aniq UI y descarga el ZIP de Full Stack.

Fíjate en qué paquete aparece elegido en la página de descarga, porque los nombres de carpeta de los pasos siguientes dependen de él.

2b. Descomprime y abre la carpeta. Descomprime el archivo y abre una terminal dentro de la carpeta dashboard-2-full-stack (en Windows, descomprímelo antes con el Explorador de archivos).

Mira el contenido de la carpeta: deberías ver back-end, front-end y docker-compose.yml uno junto al otro.

2c. Arranca las dos aplicaciones.

docker compose up --build

En el primer arranque Docker construye dos imágenes y carga la base de datos, así que dale unos minutos. Los arranques siguientes tardan segundos.

Mira la terminal: primero muestra el progreso de la construcción, y el dashboard espera a que la API indique que está en buen estado.

2d. Ábrelo. Ve a localhost:3030 y usa la cuenta admin@example.com con la contraseña Admin@123. El árabe está en /ar. La API responde en localhost:8000/api/health cuando su base de datos está lista.

Qué comprobar: la dirección de salud debe responder y el dashboard debe mostrar datos en su primera pantalla. Lo que suele salir mal: un puerto ya en uso. Si otro programa ocupa el 3030 o el 8000, crea un archivo llamado .env junto a docker-compose.yml y define DASHBOARD_PORT=3040 (o API_PORT para la API), y luego ejecuta el mismo comando otra vez. Un arranque que parece atascado normalmente sigue cargando los datos de ejemplo.

Para detener las aplicaciones, pulsa Ctrl+C. Tus datos se quedan en un volumen de Docker. Ten cuidado con docker compose down -v: la opción -v borra el volumen, y el siguiente arranque trae datos de ejemplo nuevos.

3. Conoce las otras formas de ejecutarlo

No usarás todas, pero cada una resuelve una situación real.

Solo el dashboard. Con el paquete Admin Dashboard, construyes una imagen y arrancas un contenedor. Si no defines ninguna dirección de API, funciona con su servidor simulado y no necesita back end.

Fíjate en el nombre de la carpeta en la terminal: este paquete se extrae en una carpeta distinta a la de Full Stack.

Mira la salida de la construcción: las dependencias y la compilación ocurren dentro de la imagen, así que la primera construcción necesita conexión a internet.

Solo la API. Con el paquete Backend API, construyes una imagen y la ejecutas con un volumen que guarda el archivo de la base de datos. La primera ejecución carga en esa base de datos los registros y cuentas de ejemplo. Todas las rutas cuelgan de /api, y la compruebas con la dirección de salud.

Mira los archivos de la carpeta, entre ellos un Dockerfile, package.json y .env.example.

Mira la imagen que se construye: la imagen de la API es independiente de la del dashboard.

Mira la comprobación de salud del final: una API que funciona responde con el estado ok.

Sin Docker. Instala Node.js 22.9 o posterior y ejecuta corepack enable una vez. Arranca primero la API, porque el dashboard lee todos sus datos de ella. En back-end, copia los ajustes de ejemplo, crea la base de datos con yarn seed y ejecuta yarn dev. En front-end, copia los ajustes de ejemplo y arráncalo del mismo modo.

Mira la primera terminal, que ejecuta la API.

Mira la segunda terminal, que ejecuta el dashboard contra la API de la primera.

El mismo método sirve para los paquetes de una sola aplicación.

Fíjate en lo poco que hace falta aquí: sin archivo .env, responde el servidor simulado.

Mira cómo la terminal de la API se queda abierta mientras la usas.

Lo que suele salir mal: un Node.js anterior a la 22.9, que hace que yarn dev falle al leer .env; un Yarn que responde con la versión 1.22 porque Corepack está desactivado; y un dashboard que muestra datos de ejemplo aunque querías usar tu API, porque la dirección de la API faltaba cuando se construyó.

4. Explora los datos de ejemplo antes de cambiar nada

La carga inicial trae los registros de una pequeña empresa: una docena de administradores, cinco roles con 25 permisos, 15 usuarios, 15 proyectos, 10 tareas y 13 ajustes de la aplicación, además de algunos usuarios y proyectos borrados para practicar la restauración. Recorre la barra lateral de arriba abajo, hasta la página que lista todos los componentes de la interfaz.

Fíjate en cómo la barra lateral agrupa las pantallas, porque más adelante renombrarás y recortarás este menú.

Mira la parte superior del resumen: cifras clave, gráficos, un calendario y tareas rápidas comparten una pantalla, y los widgets se pueden reordenar.

Después cierra sesión e inicia sesión como john.smith@admin.com con la contraseña admin123. Esta cuenta tiene el rol Viewer. Puede leer todas las listas, pero no puede crear, editar ni borrar nada, y no puede abrir el asistente. Ver esa diferencia pronto te dice cómo se comporta el sistema de permisos, lo cual importa para el paso 6.

Qué comprobar: puedes explicar, en una frase cada uno, qué pueden hacer Super Admin y Viewer. Lo que suele salir mal: la gente edita primero los registros de ejemplo y luego olvida cuáles son datos reales. Deja intactos los datos de ejemplo hasta que estés listo para reemplazarlos de una vez.

5. Pon el nombre de la agencia

Toda la marca está en la carpeta del dashboard (front-end en el paquete Full Stack). Ejecuta yarn dev allí mientras editas y la página se recarga con cada guardado. Cuatro lugares importan más:

• src/config/brand.config.ts contiene BRAND_CONFIG: el nombre, la empresa, los metadatos de la página y los datos de la aplicación instalada, en inglés y árabe.
• public/assets/images/logo-for-lightmode.png y logo-for-darkmode.png son los dos logotipos. Reemplaza los archivos y conserva los nombres.
• src/styles/theme-variables.css define cada color una vez para el modo claro y otra para el oscuro. El color de marca es --primaryColor.
• messages/<namespace>/en.json y ar.json contienen cada palabra que se ve en pantalla. Edita los dos idiomas a la vez.

Larkspur cambia el nombre, sustituye los dos logotipos y elige un nuevo color primario. Eso basta para que el dashboard se sienta suyo. Los componentes leen los colores mediante variables como bg-[var(--surface)], así que cualquier componente que añadas después mantendrá los dos temas si hace lo mismo.

Mira la página de componentes: es la forma más rápida de ver tu nuevo color en todo tipo de controles a la vez.

Qué comprobar: cambia entre claro y oscuro en la cabecera y abre la página de componentes en ambos. Lo que suele salir mal: un logotipo con un color de fondo incrustado que se ve mal en uno de los temas. Exporta los dos logotipos con fondo transparente.

6. Configura el personal y los roles

La carga inicial trae cinco roles: Super Admin, Admin, Manager, Editor y Viewer. Una persona puede tener más de un rol y recibe los permisos combinados de todos. Los permisos se nombran módulo.acción, por ejemplo users.view, projects.edit o settings.edit, y hay 25 repartidos entre administradores, roles, usuarios, proyectos, ajustes y el asistente.

Larkspur asigna a su equipo así: el dueño sigue como Super Admin, los dos jefes de proyecto pasan a Manager, los desarrolladores a Editor y los colaboradores externos a Viewer. Hazlo en tres pasadas:

1. Abre Admin Roles y lee qué concede cada rol. Renombra o recorta hasta que los roles coincidan con el plan en papel.
2. Abre Admin Management y crea a cada persona real, y luego asígnale sus roles.
3. Inicia sesión como una persona por rol y prueba las acciones que ese rol debe y no debe tener.

Si cambias un rol mientras alguien tiene la sesión abierta, sus menús y botones se actualizan sin recargar, porque la API avisa a su dashboard por WebSocket.

Mira las etiquetas de rol de cada cuenta: muestran de un vistazo quién tiene qué rol.

Mira cómo se agrupan los permisos por módulo, lo que facilita conceder «ver» sin «editar».

Antes que nada, cambia las contraseñas de los administradores de ejemplo en Settings, Security, o elimina esas cuentas. La carga inicial las crea con contraseñas que aparecen en la documentación pública, y las guías de la plantilla lo advierten más de una vez por una buena razón.

Lo que suele salir mal: borrar al Super Admin antes de que otro administrador pueda gestionar los roles, o dar el rol Admin a todo el mundo porque es más cómodo. Empieza con reglas estrictas y afloja cuando alguien lo pida.

7. Carga los proyectos y las cuentas de clientes

Abre Projects y reemplaza las filas de ejemplo con el trabajo real de Larkspur. Un proyecto lleva un nombre y una descripción en inglés y árabe, un estado (in-progress, ready o blocked), un entorno, una versión y una imagen opcional. Borrar es un borrado lógico: los proyectos borrados pasan a su propia pantalla y se pueden restaurar.

Los usuarios funcionan igual. Puedes acotar la lista por nombre de usuario, correo, teléfono, nombre o fecha de alta, y la parte superior de la página cuenta las cuentas verificadas, sin verificar y borradas. Para Larkspur, es la pantalla del personal de clientes que recibió una invitación y nunca la confirmó. La ruta de reenvío de verificación responde con éxito pero no envía ningún correo, así que conecta tu propio servicio de correo antes de depender de ella.

Mira los contadores sobre la tabla y las etiquetas de estado de cada fila.

Si tu producto tiene otros registros, la API es REST sencilla bajo /api, así que puedes añadir módulos junto a los existentes. Inicia sesión con POST /api/auth/login para obtener el token que necesita cada otra llamada, y envíalo como bearer token. Las listas aceptan page y page_count, con un máximo de 100 por página.

Qué comprobar: crea un proyecto en inglés y árabe, recarga y confirma que ambos nombres aparecen al cambiar de idioma. Lo que suele salir mal: rellenar solo el nombre en inglés, lo que deja la lista en árabe con una etiqueta vacía.

8. Activa el asistente de IA

El asistente tiene su propia pantalla. Escribes una pregunta en inglés o árabe y la respuesta se construye con los datos del dashboard, dibujada con las mismas tarjetas de estadísticas, tablas, listas, gráficos de anillo y gráficos que usa el resto del panel. También puede actuar: añadir, cambiar, eliminar o recuperar usuarios, y ajustar la configuración de la aplicación. Lo hace solo dentro de los permisos de la persona que pregunta.

Funciona con Google Gemini, OpenAI o DeepSeek, elegidos en un selector de modelo. Las conversaciones se guardan por administrador en una barra lateral de historial. Tienes dos maneras de aportar una clave:

• Pon la clave del proveedor en back-end/.env y reinicia la API (con Docker Compose, ejecuta docker compose up otra vez). Entonces todos los que tengan acceso usan tu clave.
• Deja el servidor sin clave. Entonces el asistente pide a cada persona la suya, y se queda en su navegador.

Larkspur empieza con la segunda opción, para que el uso de nadie caiga por accidente en la factura de la agencia. La documentación dice que Gemini funciona con claves gratuitas, mientras que OpenAI necesita facturación activada en la clave. Una clave gratuita puede agotar su cuota, y el asistente lo indica; elige otro modelo o espera.

Controla el acceso con el permiso ai_chat.use. Como el asistente puede escribir, dáselo solo a los roles en los que confiarías para esas escrituras. Los colaboradores externos con el rol Viewer no reciben ninguno.

Mira cómo la respuesta mezcla un resumen escrito con un gráfico construido a partir de las propias cifras del dashboard.

Existen dos extras opcionales. Un bucket de Cloudflare R2 permite subir fotos de perfil y archivos adjuntos de imagen; sin él, las subidas responden que no están configuradas y todo lo demás funciona. Una clave MCP que elijas activa el endpoint MCP de la API; sin ella, ese endpoint rechaza todas las peticiones.

Qué comprobar: haz tres preguntas cuya respuesta ya conozcas, como cuántos proyectos están bloqueados, y compara. Lo que suele salir mal: el cuadro de diálogo que pide una clave de API, que solo significa que el servidor no tiene clave para el modelo que elegiste. Pega la tuya, o añade la clave del proveedor al archivo del servidor y reinicia.

9. Revisa el árabe y los demás detalles de idioma

Abre /ar. La página define lang="ar" y dir="rtl" antes de dibujarse, así que la barra lateral pasa a la derecha y las tablas y los menús se leen de derecha a izquierda. La API también responde en árabe cuando una petición envía Accept-Language: ar, y los proyectos, los ajustes y los países llevan ambos idiomas en la base de datos.

Todo lo que añadas debe usar clases lógicas de Tailwind como ms-2, pe-4, start-0 y text-start en lugar de ml-*, pr-*, left-* o text-left, o la página en árabe saldrá mal. Si alguna vez necesitas un tercer idioma, añade su código en tres listas de idiomas, copia cada archivo en.json con el nuevo código y añádelo al menú de idiomas. La API sigue respondiendo en inglés a un idioma nuevo hasta que añadas sus traducciones en back-end/src/i18n/.

Qué comprobar: recorre en árabe cada pantalla que hayas cambiado, incluido el asistente. Lo que suele salir mal: un texto añadido solo a en.json, de modo que la página en árabe muestra una clave que falta.

10. Publícalo en un servidor

El mismo docker-compose.yml que funcionó en el portátil también funciona en un servidor. Dale al dashboard y a la API un dominio a cada uno detrás de Caddy o Nginx, que añade HTTPS, y dirige el primer dominio al puerto 3030 (el dashboard) y el segundo al puerto 8000 (la API).

Crea .env junto a docker-compose.yml y define DASHBOARD_URL y API_URL con las dos direcciones públicas. El dashboard incorpora la dirección de la API en su código compilado, y la API toma esas mismas dos líneas para CORS_ORIGIN y FRONTEND_URL. Pon tus claves de IA y TRUST_PROXY=1 en back-end/.env. Después arráncalo en segundo plano:

docker compose up --build -d

En producción la API se niega a arrancar con el JWT_SECRET de ejemplo o con un CORS_ORIGIN vacío. Con Docker genera un secreto por ti y lo guarda en el volumen de datos, o puedes crear el tuyo:

node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

Cuando esté en marcha, abre https://api.your-domain.com/api/health (con tu propio dominio) y busca "status":"ok". Si lo prefieres, el dashboard solo puede ir a Vercel desde un repositorio Git privado: define ENABLE_EXPERIMENTAL_COREPACK con el valor 1, y luego NEXT_PUBLIC_API_BASE_URL, NEXT_PUBLIC_WEBSOCKET_BASE_URL y NEXT_PUBLIC_BASE_URL. Vuelve a desplegar después de cambiar cualquier valor NEXT_PUBLIC_*, porque se compila en el momento de la construcción. Deja NEXT_PUBLIC_DEMO_MODE desactivado salvo que el sitio sea una demo pública.

La base de datos por defecto es SQLite, guardada en el volumen /data. MySQL es un cambio de configuración: crea una base de datos vacía, define DB_TYPE y la conexión en back-end/.env, y cárgala con los datos iniciales. Elige MySQL si tu host no tiene disco persistente. Si ejecutas la API sin Docker en producción, yarn seed:prod crea las tablas una vez; ejecútalo una sola vez, porque una segunda ejecución restablece los ajustes de la aplicación y los permisos de los roles integrados a sus valores de ejemplo.

Qué comprobar: inicia sesión desde otro ordenador, cambia un rol y observa cómo se actualiza una segunda sesión abierta. Eso demuestra que la dirección del WebSocket es correcta. Lo que suele salir mal: páginas vacías con una línea de CORS en la consola del navegador. La API solo responde a navegadores desde las direcciones de CORS_ORIGIN, así que añade ahí la dirección real del dashboard y también en FRONTEND_URL.

Cómo se lleva el día a día

Cuando Larkspur está en línea, el trabajo se reduce a rutinas pequeñas y repetibles.

• Dar de alta a una persona. Crea el administrador en Admin Management, asígnale un rol y envíale la dirección. No compartas la cuenta de Super Admin.
• Dar de baja. Elimina la cuenta del administrador el mismo día. Como los roles se actualizan en vivo, también puedes quitarle un rol a alguien que sigue con la sesión abierta y sus botones desaparecen sin recargar.
• Cambiar lo que puede hacer un rol. Edítalo en la pantalla Admin Roles y avisa al equipo. Pruébalo con una cuenta real de ese rol.
• Restaurar errores. Los usuarios y los proyectos se borran de forma lógica. Abre la pantalla Deleted correspondiente para recuperar uno.
• Copias de seguridad. Con SQLite en Docker, los datos viven en un volumen. Haz copia de ese volumen con una frecuencia acorde a lo a menudo que cambian los registros. Con MySQL, usa la herramienta de copias de tu proveedor de base de datos.
• Actualizar. Después de cambiar código, vuelve a construir las imágenes, porque un contenedor en marcha es una instantánea del código en el momento de la construcción.
• Vigilar el asistente. Revisa de vez en cuando quién tiene ai_chat.use.

Cuánto cuesta mantenerlo

La plantilla es una compra única desde $99, y el paquete importa: el paquete Full Stack que usa esta guía cuesta más que el precio de entrada, y la página del producto lista cada uno. La licencia cubre un número ilimitado de proyectos, trabajos para clientes incluidos, siempre que no compartas el código fuente públicamente.

Más allá de eso, pagas por lo que añadas:

• Alojamiento para el dashboard y la API. Un servidor con Docker ejecuta ambos; Vercel puede alojar solo el dashboard.
• Uso de IA, si pones una clave de proveedor en el servidor. Google, OpenAI y DeepSeek facturan según sus propias páginas de precios. Si cada persona trae su clave, la factura es suya.
• Un bucket de Cloudflare R2, si quieres subir imágenes, y una clave de WeatherAPI.com si quieres el tiempo en el saludo. Ambos son opcionales.
• Un nombre de dominio y, si lo usas, un servicio de correo para los correos de verificación.

Lo que es gratis: el desarrollo local con SQLite, los datos de ejemplo, la API simulada integrada en el paquete del dashboard y cada función opcional que dejes desactivada.

Qué personalizar después

• Roles que se ajusten a tu empresa. Renombra los cinco roles y recorta sus permisos hasta que cada uno conceda solo lo que necesita el puesto.
• Tus propios registros. Añade un módulo a la API de NestJS para algo que Larkspur controle y que no sea un proyecto, como facturas o tickets de soporte, y una pantalla a juego. Cada dominio de la API tiene su propio módulo, así que uno nuevo encaja junto a los demás.
• Nuevas herramientas para el asistente. El asistente enruta a través de un registro MCP pensado para ampliarse, así que puedes enseñarle preguntas específicas de tus datos.
• Un tercer idioma. Copia los archivos de mensajes, añade el código a las tres listas de idiomas y añade las traducciones de la API.
• Código de producción más limpio. Cuando tu propia API sea la fuente permanente de datos, el script yarn remove:mock elimina el servidor simulado integrado y yarn remove:demo quita el interruptor de demo pública. Haz commit antes, porque ambos reescriben archivos.

Lista de verificación de lanzamiento

• Administradores de ejemplo eliminados o con la contraseña cambiada.
• Tu propio JWT_SECRET definido, o el generado por Docker confirmado en el volumen de datos.
• CORS_ORIGIN y FRONTEND_URL con la dirección real del dashboard.
• NEXT_PUBLIC_API_BASE_URL apunta a la API con /api, y el dashboard se construyó después de definirla.
• HTTPS delante del dashboard y de la API.
• La dirección de salud responde "status":"ok".
• Cada rol probado con una cuenta real.
• ai_chat.use concedido solo donde corresponde, y las claves de proveedor colocadas donde decidiste.
• Árabe revisado en cada pantalla que cambiaste.
• Copia de seguridad del volumen de datos o de la base de datos programada.
• Modo demo desactivado.

Errores comunes

Salir a producción con los administradores de ejemplo

Cada carga inicial crea administradores con contraseñas publicadas. Cámbialas o elimínalas antes de que nadie más pueda llegar al panel, y define tu propio JWT_SECRET.

Editar un valor NEXT_PUBLIC y esperar un cambio

Esos valores se compilan dentro del dashboard cuando se construye. Vuelve a construir (o reinicia yarn dev) después de cualquier edición, y nunca pongas un secreto en uno: cualquiera puede leerlos en el navegador.

Borrar los datos con el comando de parada equivocado

docker compose down conserva tus datos. Añadir -v elimina el volumen, y todo lo que creaste se va con él.

Las páginas quedan vacías y la consola menciona CORS

La API solo responde a navegadores desde las direcciones de CORS_ORIGIN. Si el dashboard se ejecuta en un dominio o puerto nuevo, añádelo ahí y en FRONTEND_URL.

Darle el asistente a todo el mundo

El asistente puede cambiar usuarios y ajustes. Concede ai_chat.use a los roles que deban tener ese poder y a nadie más.

Pasar a Docker el archivo de entorno de ejemplo

La imagen de la API se ejecuta en modo producción. Si la arrancas con una copia del archivo de entorno de ejemplo, ese archivo define el modo de desarrollo por encima del valor de la propia imagen. Pasa cada valor que necesites con -e en su lugar.

Preguntas frecuentes

¿Cómo creo un panel de administración con asistente de IA en Next.js?

Empieza desde un dashboard que ya tenga los roles, las listas y la pantalla de chat, y luego conecta tus datos y un proveedor de modelos. En esta plantilla, el asistente lee de la misma API que el resto del panel, así que añades una clave y tus registros en lugar de escribir la infraestructura del chat.

¿Necesito un backend?

Solo para datos reales. El paquete Admin Dashboard funciona con un servidor simulado dentro del navegador, lo cual basta para trabajo de diseño. Para un panel en producción necesitas una API, y el paquete Full Stack incluye una de NestJS.

¿Qué proveedores de IA admite el asistente?

Google Gemini, OpenAI y DeepSeek, elegidos desde una lista de modelos. Cada persona puede pegar su propia clave, o puedes definir una sola clave en el servidor.

¿Admite árabe y RTL?

Sí. Todas las pantallas, incluido el asistente, existen en inglés y árabe, y las páginas en árabe se muestran de derecha a izquierda.

¿Puedo usarla para clientes?

Sí. La licencia comercial cubre proyectos ilimitados, incluido el trabajo que creas para un cliente y le entregas. No puedes publicar el código fuente ni revenderlo como plantilla.

¿Puedo cambiar lo que el asistente tiene permitido hacer?

Tú decides quién puede usarlo con el permiso ai_chat.use, y el asistente actúa solo dentro de los permisos de esa persona. Añadir herramientas nuevas se hace a través de su registro MCP en la API.

¿Puedo probarla sin instalar nada?

Sí. La demo en vivo ejecuta el mismo dashboard. Para tu propio ordenador, el paquete Admin Dashboard funciona con sus datos de ejemplo integrados, sin API ni clave de IA.

¿Puedo quitar los datos de ejemplo y el servidor simulado?

Sí. Dos scripts, yarn remove:mock y yarn remove:demo, eliminan del código el servidor simulado y el interruptor de demo pública. Haz commit antes, porque reescriben archivos.

Pruébala tú mismo

Abre la demo en vivo para recorrer el dashboard y el asistente. La página del producto Admin Dashboard Template 2 lista los paquetes, y la documentación cubre en detalle cada paso anterior. Hay más opciones en la categoría de plantillas de dashboard de administración, y la guía de plantillas de dashboard de administración por sector te ayuda si tu caso es distinto de este.

Esta plantilla es también una de las diez del Next.js Templates Bundle, si esperas crear más de un tipo de producto.