Saltar al contenido principal

Despliega tu web gratis: GitHub, Vercel y Supabase paso a paso

9 min de lectura

Vas a tener tu web online, con dominio y HTTPS, sin pagar hosting. GitHub guarda el código, Vercel lo publica solo cada vez que lo tocas, y Supabase te da base de datos para formularios y usuarios. Con una IA como Claude Code delante, el despliegue deja de ser un ritual y pasa a ser una frase. Este es exactamente el stack con el que está hecha la web que estás leyendo. Aquí va la guía entera —la que en el vídeo solo se resume—, con los números reales y con la parte incómoda: dónde este stack se queda corto.

¿Qué son GitHub, Vercel y Supabase y qué hace cada uno?

Son tres piezas que se reparten el trabajo. No compiten entre ellas, se complementan. Piénsalo así: una guarda el código, otra lo publica y otra guarda los datos.

  • GitHub — dónde vive el código. Es el almacén de tu proyecto. Cada cambio queda registrado con su historial, puedes volver atrás si algo se rompe, y es la fuente de la verdad de la que beben las demás piezas. Sin GitHub tienes archivos sueltos en tu ordenador; con GitHub tienes un proyecto versionado que Vercel puede leer.
  • Vercel — quien coge el código y lo publica solo. Vercel se conecta a tu repositorio de GitHub y, cada vez que subes un cambio, reconstruye la web y la deja online. No tocas servidores, no configuras nada de infraestructura. Te da una URL pública, HTTPS y una red global para que cargue rápido en cualquier país.
  • Supabase — la base de datos. Cuando tu web necesita guardar algo —un formulario de contacto, usuarios registrados, un listado de productos— ese algo vive en Supabase. Es una base de datos PostgreSQL con autenticación y API ya montadas. Le pides datos desde tu web y te los devuelve.

La web más simple (una landing, un portfolio) solo necesita las dos primeras. En cuanto haya formularios o cuentas de usuario, entra Supabase.

El paso a paso real

Esta es la parte que importa. Cinco pasos, en orden.

1. Sube tu proyecto a GitHub

Desde la carpeta de tu proyecto, inicializas el repositorio y subes el código:

# Inicializa git y registra el primer commit
git init
git add .
git commit -m "primer commit"

# Conecta con tu repo de GitHub (créalo antes, vacío, en github.com)
git remote add origin https://github.com/tu-usuario/tu-repo.git
git push -u origin main

A partir de aquí, cada vez que hagas git push, el cambio queda guardado en GitHub. Y, en el siguiente paso, cada push disparará un despliegue automático.

2. Conecta el repo a Vercel

Entra en Vercel, elige importar proyecto y selecciona tu repositorio de GitHub. Vercel detecta el framework (Next.js, Astro, lo que sea) y configura el build por ti. Le das a desplegar y, en un par de minutos, tu web está online con una URL pública.

Lo importante viene ahora: a partir de esa conexión, cada git push a la rama principal republica la web sola. No vuelves a "subir la web" manualmente nunca más. Cambias código, haces push, y en un minuto está en producción.

3. Crea el proyecto en Supabase y guarda las claves como variables de entorno

Si tu web necesita datos, crea un proyecto en Supabase. Te dará dos cosas que necesitas: la URL del proyecto y la anon key (la clave pública para el cliente). Las encuentras en los ajustes de API del proyecto.

Esas claves no van en el código. Van como variables de entorno, y las configuras en dos sitios: en tu .env.local para desarrollo, y en el panel de Vercel (Settings → Environment Variables) para producción.

# .env.example  — se sube al repo SIN valores reales, solo los nombres
NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_ANON_KEY=
SUPABASE_SERVICE_ROLE_KEY=

La service_role key (la que salta la seguridad de la base de datos) jamás lleva el prefijo NEXT_PUBLIC_ ni se usa en el navegador: solo en el servidor. Volvemos a esto en la sección de seguridad, porque es donde más gente se pega el tiro.

4. Deja que Claude Code lo automatice

Todo lo anterior lo puede hacer una IA por ti. Con Claude Code delante, el despliegue es una conversación. Le das contexto y le pides el resultado:

  • Ábrele el proyecto y dile qué quieres: "conecta este proyecto a un repo nuevo de GitHub y prepáralo para desplegar en Vercel".
  • Para las claves, dale los nombres de las variables y explícale que deben ir en .env.local y en Vercel, nunca en el código. Ejemplo de instrucción: "crea un .env.example con las variables de Supabase, añade .env.local al .gitignore, y recuérdame meter los valores reales en el panel de Vercel".
  • Puede escribir los comandos de git, redactar el .gitignore, montar el cliente de Supabase y dejarte la web lista para el primer deploy.

Una regla que no se salta ni con IA: los valores reales de las claves los pones tú, a mano, en .env.local y en el panel de Vercel. A la IA le das los nombres y la estructura, no los secretos.

5. Conecta tu dominio (opcional)

Si tienes un dominio propio, en Vercel vas a Settings → Domains, lo añades y sigues las instrucciones de DNS. En unos minutos tu web responde en tudominio.com con HTTPS incluido. Si no tienes dominio, la URL gratuita de Vercel (tu-proyecto.vercel.app) funciona perfectamente para empezar.

¿Cómo protejo las claves y la base de datos?

Esta sección no es opcional. Una web mal configurada en este stack puede dejar tu base de datos abierta a cualquiera. Cuatro reglas.

  • Las claves van en variables de entorno, nunca en el código ni en el repo. Si una clave acaba en un commit, considérala comprometida: rótala. Por eso existe el .env.example con los nombres pero sin valores.
  • .env.local en el .gitignore. Siempre. Es la línea que evita que tus secretos acaben en GitHub por accidente.
# .gitignore
.env
.env.local
.env*.local
  • Activa Row Level Security (RLS) en Supabase. Esto es lo que más gente se salta. Por defecto, si expones la anon key (y la expones, es pública), sin RLS tu base de datos queda abierta a lectura y escritura para cualquiera. Con RLS defines políticas: quién puede leer qué, quién puede escribir qué. Sin RLS activo, no publiques.
  • HTTPS viene solo. No tienes que configurar certificados: Vercel sirve todo por HTTPS por defecto. Una cosa menos.

La service_role key merece su propia advertencia: salta RLS por completo. Solo se usa en el servidor (server actions, rutas de API), nunca en el navegador, y nunca con prefijo NEXT_PUBLIC_.

¿Cuánto aguanta el plan gratis? Los números reales

Aquí es donde toca ser honesto. Estas cifras son a fecha de julio de 2026 y pueden cambiar; comprueba siempre la web oficial antes de tomar decisiones.

Vercel (plan Hobby, gratis):

  • 100 GB de tráfico al mes. Para una web ligera son decenas de miles de visitas mensuales sin despeinarse. De sobra para un negocio pequeño.
  • Funciones hasta 300 segundos (5 minutos) por invocación. Suficiente para una API, enviar un email, guardar un formulario o llamar a un modelo de IA.
  • Un aviso que casi nadie lee: el plan Hobby es solo para uso personal y no comercial. Si vas a monetizar o vender con esa web, los términos de Vercel te piden pasar a Pro (unos 20 €/mes). No es un capricho suyo: está en las condiciones. Tenlo en cuenta antes de facturar desde una web en Hobby.

Supabase (plan Free, gratis):

  • 500 MB de base de datos. Son muchas filas de texto. Para formularios, usuarios y contenido de una web normal, tardas en llenarlo.
  • 50.000 usuarios activos al mes y 5 GB de egress (datos que salen de la base de datos).
  • Se pausa tras 7 días sin actividad. Este es el detalle que muerde a los proyectos con poco tráfico: si nadie entra en una semana, el proyecto se suspende y hay que reactivarlo a mano. Para un proyecto vivo no lo notarás; para uno dormido, sí.

¿Para qué sirve este stack y para qué no?

Ningún stack vale para todo. La honestidad manda, así que aquí va la parte que no sale en los tutoriales de "monta tu web en 5 minutos".

Sí, es ideal para:

  • Landings y páginas de negocio.
  • Portfolios y webs personales.
  • Webs corporativas con formularios de contacto.
  • Pequeñas apps con usuarios y datos moderados.

No, evítalo para:

  • Procesos que necesitan estar encendidos de forma permanente: un worker 24/7, un bot que escucha sin parar, colas que corren en segundo plano durante horas. Las funciones de Vercel se ejecutan por petición y terminan; no son un servidor siempre despierto.
  • Transcodificación de vídeo o cargas de trabajo muy largas. Aunque 300 segundos dan mucho juego, un proceso que tarda media hora no encaja aquí.
  • Aplicaciones muy pesadas con picos de cómputo constantes: acabarás peleándote con los límites y el modelo de costes.

Para esos casos, la respuesta no es "este stack es malo", sino "necesitas otra pieza": un servidor propio, un servicio de colas o trabajos duraderos, o una arquitectura pensada para procesos largos. Usa la herramienta adecuada para cada trabajo.

En resumen

Con GitHub, Vercel y Supabase tienes una web profesional online, gratis y con deploy automático en cada cambio; y con una IA como Claude Code, el proceso entero se reduce a decir lo que quieres. Es exactamente el stack sobre el que está montada esta misma web (notfound404.es), así que no te lo cuento de oídas.

Si prefieres no pelearte con .env, RLS y variables de entorno y que alguien te lo deje funcionando y seguro, para eso estamos: calcula tu presupuesto orientativo o escríbenos directamente. Y si quieres seguir montando cosas tú, el siguiente paso natural es entender el stack y el método completo con el que dirijo a la IA.

Calcula tu presupuesto →