Presentación comercial · Infraestructura y seguridad
Documento informativo · 13/08/2026

Para tu negocio, no para un técnico

Tu web se publica sola, se defiende sola y se recupera sola.

En REVISION ALPHA no te entregamos “un servidor y suerte”. Te entregamos un sistema completo: publicación controlada, seguridad activa y copias de seguridad pensadas para que el negocio siga funcionando aunque algo falle.

Web Cloud

Rápido, escalable y listo para crecer. Ideal cuando quieres velocidad, CDN y boost ante picos de visitas.

Servidor dedicado

Hardware exclusivo, red privada, control total y administración visual. Ideal cuando el rendimiento no se puede compartir.

La idea en una frase

Imagina que publicar tu web es como abrir una tienda física… pero con porteros, cámaras y caja fuerte.

Cuando un cliente compra en tu tienda online, no piensa en firewalls ni en Git. Piensa: “¿funciona?”, “¿es seguro?”, “¿si algo se rompe, pierdo mis datos?”.

Nuestro trabajo es que esas tres respuestas sean siempre: sí, sí y no.

Ejemplo real: Lanzas una campaña de Black Friday. Entran 10× más visitas. En Cloud, el Boost suma recursos temporalmente. En dedicado, el hardware es 100% tuyo. Si hace falta, añadimos workers y balanceadores desde el panel (Forge) sin rehacer el proyecto. En todos los casos, la seguridad y los backups siguen activos.

Cómo llega tu web al mundo

Publicamos desde Git, con llave de acceso y ramas protegidas

El código no se “sube a mano” a un servidor abierto. Viaja por un camino controlado: tu equipo trabaja en Git, solo la rama autorizada puede publicar, y Laravel Forge despliega con una clave de acceso segura.

Qué significa esto para ti

Nadie publica “por error”. La rama de producción está protegida: hace falta revisión y permiso.
Acceso con llave, no con contraseña suelta. Forge usa una clave de despliegue. No dejamos la puerta abierta.
Root protegido con sudo. El usuario administrador no trabaja “a lo loco”: las acciones críticas pasan por privilegios controlados.
Parches del sistema operativo auditados. Forge ayuda a mantener el SO al día; no esperamos a que un fallo público se convierta en un incidente.

Ejemplo: Un desarrollador termina un cambio de precios. Lo sube a Git. Otro lo revisa. Solo entonces Forge publica en producción. Si alguien intenta publicar desde otra rama, el sistema lo bloquea.

Crece cuando el negocio crece

Recursos dinámicos: workers, balanceadores y más servidores

No hace falta “cambiar de hosting” cada vez que el tráfico sube. Con Laravel Forge provisionamos y añadimos piezas según el momento: más manos en segundo plano, más servidores web y un balanceador que reparte las visitas.

flowchart TB U[Visitantes] --> LB[Balanceador de carga
Round-robin · Least connections · IP hash] LB --> W1[Servidor web 1] LB --> W2[Servidor web 2] LB --> W3[Servidor web N…] W1 --> Q[(Colas / jobs)] W2 --> Q W3 --> Q Q --> WK1[Worker 1] Q --> WK2[Worker 2] Q --> WKN[Worker N…] WK1 --> DB[(Base de datos / caché)] WK2 --> DB WKN --> DB

Workers (trabajadores en segundo plano)

Procesan emails, facturas, imports y tareas pesadas sin frenar la web. En Forge se configuran por sitio: conexión de cola, procesos, memoria y reinicio tras cada deploy. Si hay más trabajo, subimos el número de procesos o añadimos un Worker Server.

Balanceadores de carga

Un Load Balancer reparte las peticiones entre varios servidores. Métodos de Forge: round-robin (reparto equitativo), least connections (al menos ocupado) o IP hash (misma IP → mismo servidor). Se puede cambiar el método en cualquier momento.

Tipos de servidor bajo demanda

Forge permite levantar piezas especializadas cuando hacen falta: Application / Web, Worker, Load Balancer, Database y Cache. Cada una viene con el software adecuado; no improvisamos a mano.

Qué significa para ti

Picos de campaña, un nuevo marketplace o un pico de envíos de correo: escalamos en caliente desde el panel, sin parar el negocio ni reescribir la arquitectura.

Ejemplo: La tienda dispara 50.000 emails y el checkout se satura. Añadimos un balanceador delante de dos servidores web y subimos workers de cola de 2 a 8 procesos. Los clientes siguen comprando; el correo se procesa en segundo plano. Cuando baja el pico, reducimos lo que sobra.

Antes de que el código se vea en público

Revisión de secretos y vulnerabilidades (SourceGuardian)

Antes de publicar, revisamos que el código no lleve contraseñas, tokens o fallos conocidos. SourceGuardian forma parte de esa capa de control: evitamos que una vulnerabilidad “viaje” a producción junto con la nueva versión.

flowchart TD A[Commit listo] --> B{¿Hay secretos
o vulnerabilidades?} B -->|Sí| C[Se detiene la publicación] C --> D[Se corrige y se vuelve a revisar] B -->|No| E[Forge despliega] E --> F[Sitio actualizado]

Ejemplo: Alguien deja por error una clave de API en un archivo. El control lo detecta. La web no se publica hasta limpiarlo. Evitas un escape de credenciales antes de que llegue a internet.

Capas de defensa

Seguridad activa: firewall, honeypot y anti-DDoS

No bastan las contraseñas. Ponemos varias capas para que el tráfico hostil se corte antes de llegar a tu aplicación.

flowchart TB I[Internet] --> DDoS[Mitigación anti-DDoS] DDoS --> FW[Firewall CrowdSec
detecta y bloquea IPs maliciosas] FW --> HP[Honeypot externo
atrae y aísla ataques] HP --> APP[Tu web / API] APP -.->|Solo por túnel seguro| DB[(Base de datos)]

CrowdSec (firewall inteligente)

Aprende de comportamientos sospechosos y bloquea IPs maliciosas en tiempo real. Como un portero que reconoce caras conflictivas.

Honeypot externo

Una “trampa” gestionada por una compañía especializada: atrae atacantes hacia un señuelo y los aísla lejos de tu negocio real.

Anti-DDoS permanente

Cuando alguien intenta tumbarte a base de tráfico absurdo, la red lo mitiga para que tus clientes sigan entrando.

Túnel a la base de datos

La BBDD no queda expuesta a internet. Solo se alcanza por un túnel seguro. Menos superficie de ataque, más control.

Ejemplo: Un bot intenta adivinar contraseñas de administración miles de veces. CrowdSec lo detecta y bloquea la IP. El honeypot, además, captura patrones de ataque para reforzar la defensa. Tú no recibes una llamada a las 3:00 a.m.

Red y datos

La base de datos vive “dentro”, no en la calle

En servidores dedicados puedes usar red privada aislada: un canal físico separado de internet para conectar aplicación, base de datos y backups. El tráfico interno no se mezcla con el público.

Ejemplo: Un ecommerce guarda pedidos y datos de clientes. La web habla con la base de datos por red privada o túnel. Desde fuera, un atacante no “ve” el puerto de la BBDD como si fuera una puerta abierta.

Si algo falla

Backups diarios, semanales y mensuales… más copia remota de la BBDD

Una copia en el mismo disco no es un plan de recuperación: es un espejismo. Por eso las copias salen del servidor (y del datacenter) y la base de datos tiene respaldo remoto recursivo.

flowchart TD S[Servidor en producción] --> D[Backup diario] S --> W[Backup semanal] S --> M[Backup mensual] S --> R[Backup remoto recursivo de la BBDD] D --> EXT[Almacenamiento fuera del servidor] W --> EXT M --> EXT R --> EXT EXT --> REC[Recuperación cuando haga falta]

Diario: para volver a “ayer” si un cambio sale mal.
Semanal / mensual: para recuperar puntos más antiguos si el problema se detecta tarde.
Remoto + BBDD recursiva: si falla el disco o el datacenter, no pierdes el histórico de datos.

Ejemplo: Un plugin o una actualización borra contenido por error el martes. Restauramos el backup del lunes. El negocio retoma, no “reconstruye de memoria”.

Transparencia operativa

Nuestra red global, visible en tiempo real

No pedimos que “confíes a ciegas”. Puedes ver el estado de cada nodo y servicio en revisionalpha.com/status: Public Cloud, Web Cloud, Network & Infrastructure y el mapa de datacenters.

flowchart LR subgraph Red[Red global de datacenters] EU[Europa
Gravelines · Frankfurt · Londres…] AM[América
Ashburn · Beauharnois · Buenos Aires…] AP[Asia-Pacífico
Singapur · Sídney · Mumbai…] end ST[Panel /status
estado en tiempo real] --> EU ST --> AM ST --> AP EU --> OK[Tu servicio online] AM --> OK AP --> OK

Mantenimiento sin sorpresas: primero se mueve la información

Antes de tocar un nodo para mantenimiento, los datos se mueven a otro nodo. Trabajamos sobre la máquina vacía o fuera de servicio; tu información ya está sirviendo desde el destino. Redundancia + failover = alta disponibilidad.

Ejemplo: Hay que actualizar el Nodo A. Antes de apagar nada, la información ya está en el Nodo B. Los clientes siguen comprando. Cuando A termina el mantenimiento, vuelve a la red como respaldo. En /status ves si un servicio está “Monitoreando” u “en mantenimiento”.

Quién nos avala

Certificaciones y proveedores de conformidad

La confianza se demuestra con marcos auditables. Operamos con sede en España, bajo RGPD y normativa local, y nos apoyamos en certificaciones y códigos de conducta del ecosistema cloud. Detalle completo en revisionalpha.com/conformidad.

ISO 27001 / 27017 / 27018

ISO 27701

RGPD

SOC 1, 2 y 3

CSA STAR

CISPE

PCI-DSS

ENS (España)

ANSSI SecNumCloud

G-Cloud UK

HDS / datos de salud

ISO 9001 · 14001 · 50001

Enunciado comercial: “No inventamos la seguridad: nos alineamos con ISO, SOC, CSA, CISPE, PCI-DSS, ENS y marcos sectoriales (salud, finanzas, sector público). Tú eliges el nivel; nosotros traemos el respaldo normativo.”

Qué elegir

Cloud o Dedicado: misma filosofía, distinto músculo

Web Cloud — “crece conmigo”

NVMe, CDN global, boost ante picos, SSL ilimitados, anti-DDoS de aplicación, antivirus, sitios/dominios ilimitados, recursos reservados (vCores + RAM), backups y tráfico ilimitado. Escala con workers y balanceadores cuando el proyecto lo pide.

Dedicado — “esto es mío”

CPU/RAM/NVMe exclusivos, deploy Git + panel visual, seguridad activa (firewall + honeypot + anti-DDoS), red privada, backups remotos, tráfico ilimitado, root con gestión y parches desde el panel. Misma capacidad de sumar workers y balanceadores vía Forge.

Regla práctica: si tu prioridad es lanzar y escalar sin fricción → Cloud. Si necesitas potencia exclusiva, segmentación de red y control total → Dedicado.

Personas detrás de la máquina

Soporte Business: producción con respuesta rápida

La infraestructura vale poco si nadie responde cuando el negocio necesita ayuda. Con Soporte Business (recomendado para producción):

Asistencia 24×7
Canales: ticket, teléfono y WhatsApp (número específico)
Tiempo de respuesta objetivo: 30 minutos
Monitorización e intervención de hardware en datacenter 24×7

Ejemplo: Un sábado por la tarde el checkout falla tras un cambio de pasarela. Abres WhatsApp Business. En minutos hay alguien del equipo trabajando contigo, no un formulario que “responderá el lunes”.

Resumen ejecutivo

El mapa completo, de punta a punta

flowchart TB DEV[Tu equipo] -->|Git · rama protegida| FORGE[Laravel Forge] FORGE -->|Deploy key + sudo controlado| SRV[Servidor Cloud o Dedicado] FORGE -->|Parches SO auditados| SRV SCAN[SourceGuardian / revisión de vulnerabilidades] --> FORGE NET[Anti-DDoS + CrowdSec + Honeypot] --> SRV FORGE --> SCALE[Workers + balanceadores
escala dinámica] SCALE --> SRV SRV -->|Túnel / red privada| DB[(Base de datos)] SRV --> BAK[Backups D / S / M + remoto BBDD] SRV --> RED[Red global · /status en vivo] SRV --> CONF[Conformidad ISO · SOC · RGPD…] SRV --> SUP[Soporte Business 24×7] SRV --> USERS[Tus clientes online]

Enunciados listos para contar

“Publicamos solo desde una rama protegida, con llave de acceso y sin dejar el root a la deriva.”
“Antes de salir a producción, revisamos secretos y vulnerabilidades.”
“Si el tráfico crece, añadimos workers y balanceadores en caliente desde Forge, sin rehacer el proyecto.”
“El firewall CrowdSec y un honeypot externo cortan ataques antes de que toquen tu negocio.”
“La base de datos no está expuesta: se alcanza por túnel o red privada.”
“Tenemos copias diarias, semanales, mensuales y respaldo remoto de la BBDD.”
“Puedes ver el estado de cada nodo en tiempo real en /status; en mantenimiento, primero movemos la información.”
“Nos avalan marcos como ISO, SOC, CSA, CISPE, PCI-DSS, ENS y RGPD.”
“Si pasa algo en producción, Soporte Business responde en minutos, no en días.”

Hablar con el equipo