VPS para WooCommerce: configuración recomendada

Recursos iniciales

Una tienda pequeña puede empezar con 4 GB y 2 vCPU; 8 GB y 4 vCPU son más cómodos para catálogo, plugins y pedidos activos. Tiendas grandes deben medir workers, consultas y tareas, no copiar una tabla genérica.

Stack recomendado

Ubuntu LTS o Debian, Nginx, PHP-FPM vigente, MariaDB/MySQL, OPcache, HTTPS y Redis opcional. Mantén versiones soportadas y prueba actualizaciones en staging.

Caché sin romper compras

Cachea catálogo y contenido público. Excluye carrito, checkout, mi cuenta, endpoints AJAX y usuarios con cookies de sesión. Comprueba precios, moneda, stock y cupones como visitante y cliente autenticado.

PHP y base de datos

Dimensiona PHP-FPM a partir de memoria por proceso y concurrencia. Activa slow log. En la base, revisa consultas lentas, índices, autoload excesivo y tamaño de tablas de sesiones/acciones programadas.

Cron y colas

Sustituye WP-Cron por cron del sistema cuando sea apropiado. Vigila Action Scheduler: webhooks, correos y renovaciones atrasadas son una señal operativa, no solo de rendimiento.

Backups y seguridad

Respalda archivos y base con frecuencia acorde a pedidos; una copia nocturna puede perder un día de ventas. Prueba restauraciones y protege el panel, SSH y pasarelas. No guardes claves de pago en repositorios.

Consulta VPS para WordPress para dimensionamiento general y la guía de instalación. Los VPS Terranode incluyen opciones NVMe para diferentes tamaños.

Por qué una tienda exige más que un WordPress informativo

El catálogo público puede cachearse, pero carrito, cuenta, checkout, inventario y webhooks dependen de datos actuales. Cada comprador crea una sesión y varias operaciones dinámicas. Una campaña concentra esas acciones y hace que el promedio mensual pierda valor.

Dimensiona con compradores simultáneos, pedidos por minuto, tamaño de catálogo y trabajos en segundo plano. Incluye importaciones, sincronización con ERP, correos y renovaciones. Un sitio con pocas visitas pero productos variables y muchas integraciones puede exigir más que un blog concurrido.

La prueba principal no es abrir la portada: añade producto, aplica cupón, calcula envío y completa un pedido de prueba mientras hay otras sesiones.

Repartir RAM entre PHP, base y caché

Linux, servidor web, PHP-FPM, MariaDB, Redis y agentes comparten la máquina. Reserva memoria por componente y deja margen para picos. Demasiados workers PHP pueden expulsar la caché de base y empeorar todo el checkout.

Mide consumo de un worker durante una compra y multiplica por concurrencia razonable. Ajusta pm.max_children con ese presupuesto. Si la cola crece con CPU saturada, añadir workers no ayuda; si hay recursos libres, aumenta gradualmente.

Cuatro gigabytes pueden servir para una tienda pequeña optimizada. Ocho ofrecen más espacio para catálogo, procesos y picos. Ninguna cifra compensa plugins defectuosos o tareas sin límite.

Caché segura para catálogo, carrito y checkout

Cachea páginas públicas de categorías y productos cuando el stock y precio se invaliden correctamente. Excluye carrito, checkout, mi cuenta, endpoints AJAX y sesiones. Considera cookies de WooCommerce al definir reglas.

Prueba como visitante y usuario autenticado: moneda, impuestos, precio, stock, cupón y contenido del carrito. Una respuesta cacheada equivocada puede mostrar información de otra sesión o permitir comprar con datos antiguos.

Documenta quién purga la caché después de actualizar inventario. Una tasa de aciertos alta mejora catálogo; el checkout seguirá necesitando capacidad dinámica.

PHP-FPM y OPcache para tráfico de compra

Usa PHP soportado por WordPress, WooCommerce y plugins. Activa OPcache y comprueba que no se reinicia constantemente por falta de espacio. OPcache reduce compilación, pero no cachea pedidos.

Configura workers según memoria real y activa slow log. Busca solicitudes que retienen procesos: filtros, cálculo de envío, pasarelas y llamadas externas. Define tiempos de espera razonables; un proveedor lento no debe ocupar todos los workers indefinidamente.

Después de cada cambio prueba checkout completo. Una página rápida no demuestra que los webhooks o callbacks funcionen.

MariaDB: consultas, índices y conexiones

Asigna buffer de InnoDB sin tomar toda la RAM. Limita conexiones mediante PHP y revisa consultas lentas durante carga. Tablas de pedidos, metadatos y acciones programadas pueden crecer de forma diferente al catálogo.

No borres tablas ni añadas índices en producción sin copia y prueba. Actualizaciones de WooCommerce pueden usar nuevas estructuras; sigue herramientas oficiales y verifica compatibilidad. El NVMe ayuda a la entrada/salida, pero una consulta que examina demasiadas filas sigue costando.

Observa tiempo de base dentro del checkout. Si domina, optimiza consultas y caché de objetos antes de comprar CPU a ciegas.

Redis y caché de objetos

Redis reduce consultas repetidas al guardar objetos. Es útil en tiendas dinámicas, pero consume RAM y no sustituye caché de página. Instálalo solo si puedes medir su tasa de aciertos y administrar su persistencia según el uso.

Escucha en localhost o red privada, usa permisos y no publiques el puerto. Configura expulsión con cuidado: una política inadecuada puede llenar memoria o eliminar datos que la aplicación esperaba conservar. La caché debe poder reconstruirse; no guardes allí la única copia de información.

Prueba vaciado y recuperación. Si al limpiar Redis el checkout falla, existe una dependencia mal diseñada.

Action Scheduler y colas atrasadas

WooCommerce y extensiones usan Action Scheduler para correos, webhooks, renovaciones y sincronizaciones. Revisa acciones pendientes y fallidas. Una cola que crece puede indicar cron roto, error externo o capacidad insuficiente.

No elimines acciones masivamente para ocultar el síntoma: podrías perder tareas de negocio. Identifica grupo, error y reintentos. Procesa en lotes y limita concurrencia cuando el servicio externo tiene cuotas.

Mide la edad de la acción más antigua. Que el sitio abra mientras pedidos esperan horas no es una tienda sana.

Reemplazar WP-Cron por cron del sistema

WP-Cron depende de visitas y puede dispararse varias veces durante un pico. Para operación estable, programa cron del sistema y deshabilita el disparo por petición después de verificarlo.

*/5 * * * * curl -fsS https://tienda.example/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Una llamada HTTP es sencilla; WP-CLI puede dar más control si está instalado. Distribuye importaciones y backups para que no coincidan. Monitoriza resultado: programar cron no garantiza que las acciones terminen.

Pasarelas, webhooks y servicios externos

El pago puede depender de DNS, red y API externa. Mide tiempo y errores por proveedor. Configura timeouts y reintentos que no dupliquen cargos o pedidos. Cada operación debe ser idempotente cuando la integración lo admita.

Los webhooks de confirmación necesitan HTTPS válido y ruta accesible. No bloquees al proveedor con firewall o reglas antispam sin prueba. Registra identificadores de evento, no datos sensibles completos.

Un VPS más potente no acelera una pasarela lenta. Separa ese tiempo antes de diagnosticar CPU o disco.

Inventario y consistencia durante picos

El stock requiere datos actuales. Evita cachear respuestas personalizadas y prueba compras simultáneas del último artículo. Plugins de sincronización con ERP deben definir qué sistema manda y qué ocurre si la conexión falla.

Procesa actualizaciones en lotes pequeños para no bloquear tablas. Una importación completa durante ventas puede competir con checkout. Programa cambios grandes o usa una estrategia incremental.

Después del pico concilia pedidos, pagos e inventario. La disponibilidad sin consistencia no es éxito.

Imágenes, CDN y almacenamiento

Catálogos grandes generan muchas imágenes y variantes. Optimiza antes de subir, usa formatos adecuados y una CDN para estáticos. Esto reduce transferencia y trabajo del origen, pero no corrige consultas dinámicas.

Reserva disco para originales, miniaturas y regeneraciones. No ejecutes una regeneración completa durante el pico. Si separas medios en almacenamiento de objetos, prueba permisos, URLs y restauración.

La ubicación del VPS debe medirse desde compradores y pasarelas. Mantén base y aplicación cercanas.

Seguridad específica de una tienda

Usa llaves SSH, firewall, actualizaciones y mínimos privilegios. Protege administrador con MFA y limita cuentas. No almacenes datos de tarjetas; utiliza los mecanismos de la pasarela y reduce alcance de cumplimiento.

Revisa plugins abandonados y elimina los inactivos. Separa staging de producción y no copies datos de clientes sin necesidad. Protege secretos en configuración fuera del repositorio.

Una capa de seguridad que bloquea callbacks de pago puede romper ventas. Prueba reglas con los flujos reales.

Backups según el ritmo de pedidos

La frecuencia debe reflejar cuánto pedido puedes perder. Una copia nocturna puede ser insuficiente en campaña. Respalda base con mayor frecuencia que archivos si los pedidos cambian cada minuto.

Guarda copias fuera del VPS y conserva configuración, uploads y secretos. Prueba restauración completa, incluida reconciliación de pagos ocurridos después del punto recuperado. Un snapshot no sustituye ese procedimiento.

Antes de actualizar WooCommerce, plugins o PHP, toma copia y prepara reversión. No hagas el primer ensayo en producción.

Probar una campaña antes de anunciarla

Clona en staging con datos anonimizados, calienta caché y simula catálogo, carrito y checkout. Aumenta concurrencia gradualmente. Incluye webhooks, correos y acciones posteriores al pedido.

Observa percentiles de respuesta, errores, workers, CPU, RAM, base, Redis y cola. Ejecuta una tarea programada para descubrir competencia. No uses solo la portada.

Define el máximo aceptable y qué harás al acercarte: reducir tareas, ampliar plan o limitar funciones secundarias.

Monitoreo que refleja ventas

Supervisa disponibilidad externa, recursos y disco, pero añade pedidos completados, pagos fallidos, acciones atrasadas y callbacks. Un servidor verde puede estar rechazando todas las tarjetas.

Configura alertas con responsables. Distingue fallo técnico de descenso normal de ventas. Conserva logs suficientes para correlacionar pedido y evento sin guardar secretos.

Después de desplegar, observa al menos un ciclo completo de compra y tareas. Los fallos asíncronos aparecen más tarde.

Cuándo ampliar o separar servicios

Amplía RAM ante presión legítima, CPU ante saturación sostenida y disco según crecimiento. Optimiza consultas y plugins primero. Si base y PHP compiten constantemente, separarlos puede dar límites claros, pero añade red y administración.

Mueve trabajos pesados a workers cuando bloquean compras. Aísla varias tiendas si una afecta a las demás. Toda separación necesita backups, monitoreo y seguridad propios.

Repite la prueba después del cambio. Escalar sirve cuando mejora checkout, cola y estabilidad, no cuando solo aumenta una cifra del panel.

Medir por separado catálogo, carrito y checkout

Una prueba de portada no dimensiona WooCommerce. La portada y las categorías pueden salir de caché; carrito, cuenta y checkout ejecutan PHP, consultan sesión, calculan impuestos o envío y escriben pedidos. Prepara al menos cuatro recorridos: visitante que navega catálogo, búsqueda, usuario con carrito y compra completa en modo de prueba.

Registra tiempo total, tiempo de PHP, consultas, memoria del worker y errores. Prueba con productos simples y con el tipo más complejo que vendas: variaciones, reglas de precio y cálculo de envío pueden cambiar el costo. En el checkout usa una pasarela sandbox y confirma redirección, retorno, webhook y estado final del pedido. Un 200 en la página de pago no demuestra que el pedido haya quedado confirmado.

La concurrencia debe parecerse a una campaña. Cincuenta usuarios navegando páginas cacheadas no equivalen a cincuenta pagos simultáneos. Mezcla tráfico: mayoría de catálogo, una fracción de carrito y pocas compras, más los webhooks y trabajos que estas generan. Observa CPU, workers ocupados, conexiones de base y antigüedad de Action Scheduler. Si la cola sigue creciendo después de retirar carga, el sistema no recupera el ritmo.

También ejecuta una prueba negativa. Introduce un código postal inválido, rechaza el pago en sandbox y repite el envío del webhook. WooCommerce debe mostrar un mensaje útil, conservar el carrito cuando corresponda y no crear cobros o pedidos duplicados. Esta validación protege ingresos mejor que perseguir una puntuación sintética de la portada.

HPOS, tablas de pedidos y compatibilidad de extensiones

High-Performance Order Storage (HPOS) guarda pedidos en tablas específicas en lugar de tratarlos únicamente como entradas y metadatos genéricos de WordPress. Esto reduce parte del trabajo de consultas y hace más clara la separación de datos de pedidos, pero no arregla por sí solo una extensión lenta, índices ausentes o una tienda sin caché.

Antes de activarlo o cambiar su modo, inventaría pasarelas, facturación, inventario, ERP, exportadores y plugins que leen pedidos. Comprueba compatibilidad declarada y ensaya creación, reembolso, búsqueda, exportación y webhooks en staging. Un plugin que consulta directamente wp_posts puede parecer funcional en catálogo y fallar únicamente al preparar una factura o sincronizar un pedido.

Realiza backup de base y mide el proceso de sincronización con datos de tamaño real. Durante una migración, vigila espacio y bloqueos; duplicar temporalmente representaciones puede requerir más disco que el crecimiento cotidiano. No programes el cambio junto con una actualización de PHP, tema y pasarela: si aparece una inconsistencia, necesitas aislar qué variable la produjo.

Después valida conteos y estados desde la interfaz y mediante operaciones reales. Toma una muestra de pedidos pendientes, procesando, completados y reembolsados, y compárala antes y después. La aceptación no es que el panel cargue, sino que cada integración recibe el identificador y estado correctos y que una restauración permite volver a un punto conocido.

Evitar pedidos duplicados en webhooks y reintentos

Pasarelas y servicios de envío reintentan notificaciones si no reciben respuesta a tiempo. El mismo evento puede llegar más de una vez o fuera de orden. La tienda debe procesarlo de forma idempotente: reconocer el identificador externo, comprobar el estado actual y no volver a cobrar, descontar inventario o enviar la misma acción.

No bloquees el webhook mientras generas PDF, llama al ERP o envías varios correos. Valida firma y datos esenciales, registra el evento y delega trabajo pesado a una cola. Responder rápido reduce reintentos y libera PHP-FPM para compradores. Si la dependencia externa cae, aplica backoff y conserva evidencia del siguiente intento.

Vigila tres tiempos distintos: llegada del evento, creación del trabajo y finalización. Una cola aparentemente corta puede contener un único trabajo atascado que bloquea otros del mismo grupo. Revisa Action Scheduler por acción, estado e intentos; borrar todas las tareas fallidas oculta la causa y puede eliminar operaciones que el negocio todavía necesita.

Para ensayar, captura el identificador de un evento de sandbox y envíalo dos veces según las herramientas de la pasarela. Debe existir un solo efecto de negocio. Luego entrega eventos en orden invertido —por ejemplo, actualización y confirmación— y comprueba que un estado final no retrocede. Esta lógica pertenece a la aplicación e integración, no a la cantidad de CPU del VPS, pero determina cuánta carga inútil y cuántos incidentes terminan llegando al servidor.

Actualizar WooCommerce sin convertir producción en la prueba

WordPress facilita pulsar “actualizar”, pero una tienda combina núcleo, WooCommerce, tema, pasarelas y extensiones que cambian al mismo tiempo. Construye staging con una copia saneada y ejecuta el recorrido completo antes de producción. Revisa requisitos de PHP, cambios de base y compatibilidad de cada componente crítico.

La secuencia segura empieza con backup restaurable, modo de mantenimiento corto si hay migración incompatible y registro de versiones. Actualiza una familia coherente, limpia cachés y prueba catálogo, carrito, checkout, cuenta, webhooks, correos y trabajos. Mantén el release o copia anterior hasta que pasen operaciones reales controladas.

No confíes en desactivar un plugin como único rollback si la actualización ya modificó tablas o datos. Documenta qué cambios son reversibles y qué restauración exigiría volver la base completa. Si la tienda recibe pedidos durante la ventana, restaurar un backup anterior puede borrar ventas nuevas; por eso las migraciones de alto riesgo requieren reducir tráfico, mantener compatibilidad o definir cómo reconciliar pedidos.

Las actualizaciones automáticas pueden ser adecuadas para componentes de bajo impacto con monitorización, pero pasarelas, impuestos, inventario y WooCommerce merecen una política explícita. El responsable debe recibir alertas de errores PHP, fallos de cron y checks de compra, no descubrir el problema cuando un cliente reclama.

Presupuesto de memoria para una tienda de una sola máquina

En un VPS compartido por Nginx, PHP-FPM, MariaDB y Redis, reparte memoria según picos conjuntos. Mide el RSS de un worker PHP durante checkout, multiplica por pm.max_children, añade buffers de base, sistema y margen. No asignes a PHP y MariaDB toda la RAM por separado.

RAM del VPS = sistema y Nginx
            + MariaDB bajo consultas de tienda
            + PHP-FPM por worker × concurrencia dinámica
            + Redis y OPcache
            + margen para backup, actualización y pico

Si faltan recursos, protege primero el checkout: limita bots y búsquedas costosas, cachea catálogo, reduce workers de tareas no urgentes y programa backups fuera de campañas. Si la demanda legítima supera repetidamente el presupuesto, ampliar a más RAM suele ser más simple que separar componentes. Separa base o workers cuando la medición muestre competencia sostenida o necesiten disponibilidad distinta.

Correo transaccional que no retrasa el checkout

Confirmaciones, recuperación de contraseña y avisos de pedido forman parte de la operación de una tienda. Enviar por el servidor local sin autenticación suele producir entregas inconsistentes y añade reputación de IP al trabajo del VPS. Usa un proveedor transaccional autenticado, conserva el dominio y DNS bajo control de la empresa y verifica SPF, DKIM y la política DMARC según tu servicio.

El checkout no debería esperar a que se entregue cada correo. La aplicación debe registrar el pedido y delegar el envío; si el proveedor tarda, la compra continúa y el trabajo puede reintentarse. Aun así, no muestres éxito hasta confirmar que el pedido y pago quedaron persistidos. Correo en cola y pedido en cola no tienen la misma criticidad.

Prueba desde staging hacia buzones autorizados de distintos proveedores. Comprueba remitente, enlaces, codificación, adjuntos y que una plantilla no revele datos de otro cliente. Registra el identificador del mensaje y la respuesta del proveedor, pero no el contenido completo ni credenciales. Una respuesta aceptada por la API significa que el proveedor recibió el mensaje, no que llegó a bandeja de entrada.

Vigila rebotes, quejas y trabajos fallidos. Reintentar permanentemente una dirección inválida desperdicia cola y perjudica reputación; un error temporal merece backoff. Durante una campaña, separa correo comercial de transaccional para que un pico de marketing no retrase recibos y recuperación de cuentas.

Incluye el correo en el ensayo de recuperación. Tras restaurar una copia, usa modo seguro o un destinatario de prueba para evitar reenviar notificaciones antiguas a clientes. Solo habilita el flujo real cuando cron, colas y marca temporal estén reconciliados con los pedidos posteriores al backup.

Mantén además una plantilla mínima de contingencia. Si una actualización rompe el HTML del correo, una versión de texto con número de pedido, estado y enlace seguro permite seguir informando sin bloquear ventas. Verifica que el enlace obligue a autenticarse cuando muestra datos personales y que nunca incluya tokens reutilizables en logs o sistemas de analítica.