# Sitios Estáticos

Vela puede generar un proyecto solo de frontend, prerenderizado con `@sveltejs/adapter-static` y listo para desplegar en cualquier alojamiento estático.

### Sintaxis

```
$ vela create my-site --template static
```

La plantilla estática se distribuye sin directorio `data`, así que no hay ningún PocketBase que ejecutar. Compílala como cualquier otro proyecto:

```
$ vela build
```

El adaptador se configura en `vite.config.ts` con un fallback `200.html`, de modo que el enrutado en el cliente funciona en alojamientos que sirven un único documento de respaldo.

El nombre y la URL del sitio están en [`src/lib/site.ts`](/es/cli/project-structure). Define ahí `url` con la dirección donde se servirá el sitio antes de compilar para producción: todas las páginas se prerenderizan, y su enlace canónico y la URL de su imagen Open Graph se construyen a partir de ella.

### Desplegar

Sube el directorio `build` a cualquier alojamiento estático. [`vela deploy`](/es/deploy) no lo despliega: ejecuta la aplicación como un servidor Node, y se detiene en un proyecto compilado con `@sveltejs/adapter-static`. Para servir el sitio desde tu propio servidor, cambia el adaptador a `@sveltejs/adapter-node`. Para eso no hace falta backend.

### Convertir un proyecto existente

Un proyecto creado con la plantilla por defecto puede prescindir de su backend, lo que elimina la base de datos, las migraciones y el middleware de PocketBase, y cambia el adaptador a `@sveltejs/adapter-static`:

```
$ vela disable backend
```

[`vela enable backend`](/es/enable/backend) lo vuelve a añadir.

### Comandos sin backend

Los comandos que necesitan la base de datos se detienen y lo indican, remitiendo a [`vela enable backend`](/es/enable/backend). Un proyecto tiene backend cuando tiene un directorio `data` y depende de `pocketbase-sveltekit` o de `@velastack/pocketbase`. Estos funcionan sin ella:

- `vela dev`, `vela build` y `vela preview`
- `vela ui`, `vela legal`, `vela routes` y `vela i18n`
- `vela generate schema` y `vela generate form`, y `vela destroy` para ambos
- `vela enable` para `ai`, `analytics`, `backend`, `blog`, `cms`, `content-negotiation` e `i18n`
- `vela disable` para `ai`, `analytics`, `content-negotiation` e `i18n`
- `vela cms`, y los comandos de cuenta: `signup`, `login`, `logout` y `whoami`
- `vela deploy`, una vez que el proyecto usa adapter-node, y los comandos de servidor, como `provision`, `env`, `status` y `logs`

### Limitaciones

#### Las acciones de formulario no están soportadas

Las acciones de formulario necesitan un servidor. Cualquier formulario generado que haga POST a `+page.server.ts` tiene que sustituirse por un envío desde el cliente a un endpoint externo.

#### La autenticación de usuarios no está soportada

Las compilaciones estáticas no admiten renderizado dinámico en el servidor, así que el módulo de autenticación y su grupo de rutas protegidas no tienen dónde ejecutarse.

#### Sin base de datos en tiempo de petición

Los datos pueden leerse en tiempo de compilación e incrustarse en las páginas prerenderizadas, pero no hay base de datos que consultar una vez desplegado el sitio.