¿Qué es un servidor? Guía en lenguaje sencillo para creadores de apps

Un servidor es un ordenador —o un programa que se ejecuta en uno— que espera peticiones y las responde. Cuando abres una web, tu navegador (el cliente) envía una petición a través de internet, y un servidor en algún lugar devuelve la página, las imágenes o los datos. Todas las apps que usas, desde el correo electrónico hasta la banca en línea, dependen de servidores que hacen esto millones de veces al día.

Por qué importan los servidores cuando creas con IA

Cuando un creador con IA te hace una app, parte del código se ejecuta en el navegador del visitante y parte suele ejecutarse en un servidor. La parte del servidor hace las cosas en las que el navegador no puede confiar o que no puede hacer por sí solo:

• Guardar y cargar datos desde una base de datos.
• Mantener los secretos, como las claves de API de pagos o de proveedores de IA, que nunca deben llegar al navegador.
• Comprobar permisos, asegurándose de que un usuario solo vea y modifique sus propios registros.
• Comunicarse con otros servicios: cobrar una tarjeta, enviar un email, llamar a un modelo de IA.

Saber qué hace el servidor te ayuda a entender dónde viven de verdad las reglas de tu app, por qué algunos cambios necesitan volver a publicar y qué pagas cuando alojas una app. Para la división entre las dos mitades, consulta front end frente a back end.

Una analogía cotidiana

Un servidor es como el personal de ventanilla de una oficina de correos. No sale a buscar clientes; espera. Un cliente (el cliente de la comunicación) se acerca con una petición —«quiero enviar este paquete», «¿tengo correo?»—, el empleado la gestiona y devuelve un resultado. Un mismo empleado puede atender a muchos clientes uno tras otro, y una oficina ocupada abre más ventanillas.

La oficina de correos también tiene reglas que el cliente no puede saltarse: para recoger un paquete tienes que enseñar un documento de identidad. Eso es lo que hace el servidor en una app: el navegador puede pedir cualquier cosa, pero el servidor decide qué recibe.

Cómo llega una petición a un servidor

Cuando alguien visita https://reservas.example.com/horario:

1. Búsqueda DNS. El navegador pregunta al sistema de nombres de dominio a qué dirección IP apunta reservas.example.com. Consulta cómo funcionan los dominios y el DNS.
2. Conexión. El navegador se conecta a esa dirección, por el puerto 443 para HTTPS, y establece una conexión cifrada. Consulta qué es HTTPS.
3. Petición. Envía una petición HTTP: GET /horario.
4. Trabajo. El servidor ejecuta el código que gestiona /horario —quizá buscando las reservas de hoy en la base de datos.
5. Respuesta. Devuelve un código de estado (200 OK) y el contenido: una página HTML o datos JSON que la página muestra.

Todo esto suele tardar una fracción de segundo.

Tipos de servidores que oirás nombrar

Ten en cuenta que «servidor» significa tanto la máquina como el programa. «El servidor se ha caído» puede referirse a cualquiera de los dos.

Un ejemplo práctico: una app de reservas para una peluquería

Esto es lo que hace el servidor en una pequeña app de reservas para una peluquería:

• Un visitante abre la web. El servidor (o una CDN delante de él) envía los archivos de la página.
• La página pide al servidor GET /api/huecos?date=2026-10-03. El servidor consulta en la base de datos los huecos libres y los devuelve como JSON.
• El visitante reserva las 14:00. La página envía POST /api/reservas. El servidor comprueba que el hueco sigue libre —no se fía de lo que dice el navegador—, guarda la reserva y devuelve 201 Created.
• El servidor llama a un servicio de email con una clave secreta, guardada en el servidor, para enviar la confirmación.

Si apagaras el servidor, la página podría seguir cargándose desde una CDN, pero no podría mostrar huecos ni guardar reservas.

Lo que necesita un servidor para funcionar bien

• Memoria (RAM) y CPU. Con poca memoria, la app se cae bajo carga; con poca CPU, se ralentiza.
• Estar en marcha. Un servidor apagado no puede responder. Algunas plataformas duermen las apps inactivas y las despiertan con la siguiente visita, lo que ahorra dinero pero puede hacer más lenta la primera petición.
• Configuración y secretos, proporcionados como variables de entorno.
• Registros (logs): el historial del servidor de lo que ha ocurrido, que es lo primero que miras cuando algo se rompe.
• Actualizaciones y parches de seguridad, que el alojamiento gestionado hace por ti.

Ideas erróneas habituales

• «La nube significa que no hay servidores». La nube son servidores de otras empresas, alquilados por hora o según el uso.
• «Un servidor es un ordenador grande y especial». Cualquier ordenador puede hacer de servidor. Tu portátil ejecuta uno cuando abres localhost durante el desarrollo.
• «Si el botón está oculto, los usuarios no pueden hacerlo». Cualquiera puede enviar peticiones directamente a tu servidor. Las comprobaciones de permisos deben hacerse en el servidor, no solo en la página.
• «Más servidores arreglan la lentitud». A menudo la causa real es una consulta lenta a la base de datos o una API externa. Localiza primero el cuello de botella.
• «Necesito gestionar un servidor para tener una app». Las plataformas gestionadas ejecutan los servidores por ti; tú despliegas el código y ellas se ocupan de las máquinas.

Qué pedir a tu creador de apps con IA

• «¿Qué partes de esta app se ejecutan en el servidor y cuáles en el navegador?»
• «Guarda todas las claves de API en el servidor y léelas desde variables de entorno.»
• «Comprueba los permisos en el servidor en cada petición que lea o modifique datos.»
• «¿Dónde encuentro los registros del servidor y qué dicen sobre este error?»
• «¿Esta app necesita un servidor, o puede ser un sitio estático?»
• «¿Qué pasa con la primera petición después de que la app haya estado inactiva?»

Servidores en Mythex

En Mythex no configuras ni gestionas servidores. Mientras construyes, tu app se ejecuta en un entorno de nube privado para la vista previa en vivo. Cuando publicas, Mythex la despliega: los front ends estáticos como sitios estáticos, y los back ends (Node, Python, C#, Java y otros) como contenedores creados a partir de un Dockerfile, sin que tengas que configurar ningún alojamiento. Mythex elige el tamaño de la máquina al desplegar: por defecto 1 CPU y 512 MB de memoria, con más disponible bajo petición (hasta 1 GB en Free, y hasta 2 CPU, 4 GB y 3 máquinas en Pro). Las apps publicadas se duermen cuando están inactivas y se despiertan con la siguiente visita, y una app dormida no consume nada de cómputo. Los detalles están en la documentación sobre back ends de API y límites de alojamiento, y nuestra guía de alojamiento web cubre el panorama general.

Preguntas