---
title: Sitios locales
description: Crea y opera sitios WordPress y estáticos en tu máquina.
sidebar:
  label: Sitios locales
  order: 5
---

El flujo diario sin panel: sitios WordPress o planos servidos localmente, con backups, snapshots e historial.

Un **sitio local** es una carpeta en `~/Plak/Sites/<nombre>.localhost` con su base de datos en MariaDB y su HTTPS local. Lo creas una vez con `plak add` (o lo importas/clonas) y después lo abres cada día en el navegador o en el [dashboard](/cli/dashboard). Todo lo de esta página también existe con botones en el dashboard; aquí está la versión terminal, pensada para scripts y agentes.

:::tip
Si el sitio es para un agente, añade `--agent` (o no pongas nada cuando `wp-mcp-cli` esté instalado: ya nace agent-ready). El detalle está en [MCP](/cli/mcp).
:::

## Crear y listar

### Crear, importar y clonar

```bash
plak add <nombre> [--plain] [--agent|--no-agent] [--no-reload]
plak add mi-sitio --wp-version 6.8.1
plak add dev-sitio --wp-version nightly
plak add estático --plain
plak import <nombre> <backup.zip> [--plain] [--yes] [--no-reload]
plak clone <origen> <destino> [--yes] [--no-reload]
```

- `--wp-version` acepta `latest`, `nightly` o una versión concreta; `--multisite subdomains|subdirectories` crea multisitio (incompatible con `--plain` y con `--agent`).
- WordPress nuevo usa `WP_ENVIRONMENT_TYPE=local` con debug activado. Si el aprovisionamiento falla, solo se limpia lo creado por ese intento; si solo falla el reload, el sitio queda creado e indica cómo reintentarlo.
- `import` acepta ZIP, tar.gz, tgz o tar con un árbol WordPress de un solo sitio y un SQL reconocible (incluye exportaciones de Plak, Local y hostings). Rechaza rutas fuera del destino, SQL ambiguo o multisitio.
- `clone` duplica archivos y base de datos con URLs reescritas; empieza con logs vacíos y sin dominios exclusivos ni vinculaciones remotas.

### Ver, entrar y borrar

```bash
plak list [--totals]
plak list --json
plak path <nombre>
plak url <nombre>
plak log [sitio] [-f]
plak login <sitio> [<usuario>] [--subsite <id>] [--raw]
plak delete <nombre> [--force|--yes]
plak rename <anterior> <nuevo>
```

- `login` genera un enlace único de WordPress (cualquiera o primer administrador; `--raw` imprime solo la URL).
- `log` muestra la cola del log global de PHP (`~/Plak/Logs/errors.log`) o, con sitio, sus access logs de Caddy (`caddy.log`, `caddy-lan.log`): últimas 50 líneas, o en directo con `-f`.
- `delete` borra directorio, base de datos, directiva Caddy y entradas de `/etc/hosts` (con `sudo`); sin TTY no pregunta. `rename` mueve directorio y base de datos con `search-replace` de URLs y regenera el servidor siempre.

## WP-CLI y agentes

```bash
plak wp <sitio> <argumentos wp-cli...>
plak wp mi-sitio plugin list --format=json
plak agent <sitio> [--json]
```

`plak wp` usa el runtime FrankenPHP del sitio; lo que sigue al nombre pasa intacto a WP-CLI. Los sitios nuevos son agent-ready por defecto cuando `wp-mcp-cli` está instalado (`--agent` lo fuerza, `--no-agent` lo omite, incompatible con `--plain`). `plak agent` repara de forma idempotente: instala WP-MCP y HTML Editor, rota la Application Password, refresca el perfil `wp-mcp-cli` y verifica habilidades.

## Migraciones

```bash
plak pull [<sitio>] [--yes] [--proxy-uploads]
plak push [<sitio>] [--yes]
```

`pull` y `push` envían un motor Plak al remoto por SSH y lo ejecutan allí: el remoto no necesita internet ni URL pública, y el backup viaja por SSH. Antes de tocar la base de datos remota comprueban herramientas y cancelan con un mensaje útil si falta alguna. El ayudante y el backup se eliminan al terminar y en fallos controlados. Con vinculación del panel, el destino se revalida primero (ver [Vincular y migrar](/cli/vincular)).

## Base de datos, snapshots e historial

### Base de datos

```bash
plak db backup
plak db list [--json]
plak db port [set <puerto>] [--yes] [--dry-run]
```

`backup` vuelca cada WordPress a `private/database-backup-*.sql`. `list` muestra credenciales y tamaños. `port` consulta o cambia el puerto de MariaDB, con rollback si la verificación falla.

### Snapshots

```bash
plak snapshot <sitio> create [--note <texto>] [--json]
plak snapshot <sitio> list [--json]
plak snapshot <sitio> restore <id> [--yes]
plak snapshot <sitio> delete <id> [--yes]
plak snapshot <sitio> export <id> [--output <ruta>]
```

Puntos locales de archivos + base de datos (`private/snapshots/<id>`); los estáticos solo capturan archivos. Restaurar guarda antes una snapshot de seguridad. `export` descarga la snapshot como ZIP portable con sus partes internas (`files.tar.gz` y `database.sql`): es una copia de archivo, no un backup válido para `plak import`.

### Historial

```bash
plak history <sitio> save [--note <texto>] [--background]
plak history <sitio> list
plak history <sitio> show <id> [<ruta>]
plak history <sitio> diff <de> <a|current> [<ruta>]
plak history <sitio> restore <id> <ruta> --yes [--background]
plak history <sitio> recover --yes
plak history <sitio> jobs
plak history <sitio> schedule hourly|daily --enable
plak history <sitio> schedule --disable
```

`history` versiona `wp-content` (`plugins/<slug>`, `themes/<slug>`, `mu-plugins/...`) con salida siempre JSON; solo archivos, sin base de datos ni activaciones. `restore` y `recover` exigen `--yes` incluso con TTY.

## Core, multisitio y red

### Core

```bash
plak core list
plak core mi-sitio --check
plak core update mi-sitio --version 6.8.2
plak core update --all --version 6.8.2
```

Conserva `wp-content` y `wp-config.php`, ejecuta la actualización de esquema e informa la versión efectiva. Haz snapshot antes: ni los fallos ni los downgrades restauran la base de datos solos.

### Multisitio y red

```bash
plak network <sitio> [--json]
plak network create <sitio> <slug> [--title <título>]
```

Inspecciona la red multisitio o crea subsitios (normaliza su URL a `https`). Solo red raíz local bajo `<sitio>.localhost`.
