Hosting VPS

Una máquina virtual completa, uno de 17 tamaños, sin nada nuestro instalado en ella.

Un VPS de Xuda no es un contenedor. proxmox_create_server emite POST /nodes/<node>/qemu/<template_vmid>/clone con full: 1, una copia completa de una plantilla QEMU sobre hardware de Xuda, y deploy_module realiza 84 llamadas a rutas /qemu/ y cero a /lxc/. El tamaño que usted elige se copia tal cual en lugar de interpretarse: slug_to_farm_spec devuelve { cores: s.cpu, ram_gb: s.ram, disk_gb: s.disk }, la creación escribe cores y memory como ram_gb x 1024 MB, y luego redimensiona scsi0 a disk_gb. Hay 17 tamaños dentro del grupo de servidores vps, en cuatro tipos, que van desde 1 vCPU con 0.5 GB y 10 GB por $2.50 al mes hasta 32 vCPU con 256 GB y 7200 GB por $2606. En cuanto el clon arranca, la plataforma se detiene. La rama de instalación está condicionada por if (_conf.is_debug && !isVpsApp), así que un VPS de cliente no recibe runtime, ni agente, ni stack instalado: es una imagen de nube limpia con las claves que usted suministró. proxmox_apply_firewall retorna de inmediato con la cadena vps: customer-managed firewall, y el documento de firewall por aplicación que se escribe después lleva arreglos inbound y outbound vacíos con la aplicación desactivada. deploy_vps no declara min_plan, así que cualquier cuenta, incluida una gratuita, puede crear uno. Lo que usted compra aquí es la máquina y el hardware que la sostiene, no una plataforma gestionada encima.

Clon QEMU, full: 1, nunca un contenedor
17 tamaños, de $2.50 a $2606 al mes
Imagen limpia, cinco opciones de SO, sin agente
Una máquina virtual completa, uno de 17 tamaños, sin nada nuestro instalado en ella.
17

Tamaños de VPS, en cuatro tipos, un solo grupo de servidores

2,50 US$

Tamaño de entrada: 1 vCPU, 0.5 GB de RAM, 10 GB de disco

5

Imágenes de SO en la granja, y ningún marketplace

730.5

Horas del mes de facturación, prorrateadas por hora

Los cuatro tipos

Cuatro tipos, y el tipo es lo que elige su disco.

Los 17 slugs de vps se agrupan en cuatro tipos, y el tipo no es una etiqueta de marketing. Se lee dos veces. Una en config.json, donde PRICE_OBJ.server_types lleva la descripción de una línea con la que se publica cada tipo, y otra en deploy_module, donde SERVER_TYPE_DISK_PREF convierte el tipo en una lista ordenada de clases de disco aceptables para la ubicación. Lea cada tarjeta con sus dos chips: el de la izquierda es la cadena de disco que recorre el ubicador, el de la derecha es el rango de precio y los tamaños que contiene. Todo lo demás en un plan es aritmética sobre tres números.

La cadena de disco es una preferencia que se recorre en orden, no una garantía escrita en la máquina. Un nodo de la granja sin clase de disco etiquetada cuenta como nvme, así que en la flota tal como está hoy todos los tipos, incluido el compartido, terminan en NVMe. La ubicación también exige un 20 por ciento de holgura antes de usar un nodo: los cores, la RAM y el disco solicitados se multiplican cada uno por 1 + proxmox.headroom_pct / 100 y se comparan con la capacidad libre de ese nodo.
Tres variantes, un solo camino

VPS, Full Stack VPS y Xucode son el mismo clon con una bandera encima.

Tres productos en el panel, una sola función por debajo. deploy_full_stack_vps marca app_type_override y delega en deploy_vps. deploy_xucode hace lo mismo con un override distinto, y antes descarta farm_spec y create_datacenter de la solicitud, de modo que el tamaño proviene del derecho de uso y no de quien llama. Esa forma es deliberada: un app_type distinto quedaría fuera de las ramas de vps para firewall, redimensionado, encendido, ruta web y estado, así que la variante viaja en una bandera. Lea la tabla por columnas para saber qué recibe, y por filas para ver lo poco que realmente cambia.

VPS
Full Stack VPS
Xucode
Cómo se creadeploy_vps directamente. Sin override.deploy_full_stack_vps establece app_type_override y luego llama a deploy_vps.deploy_xucode establece el override, fuerza app_hosting_preference a global y luego llama a deploy_vps.
Qué instala XudaNada. La rama de instalación está condicionada por if (_conf.is_debug && !isVpsApp), y la aplicación se marca como activa en cuanto la VM figura como running.La misma imagen limpia, más dos elementos escritos alrededor: una clave de API de CPI acotada, generada antes del aprovisionamiento, y una CouchDB por aplicación creada con create_db.El mismo camino de vps, con una máquina por cuenta en lugar de una por proyecto. Una segunda solicitud se responde con la primera máquina.
Qué se le facturaEl precio del slug, prorrateado contra un mes fijo de 730.5 horas a partir de las marcas de tiempo de app_cost, con un segmento facturable mínimo de una hora. Sin cron de facturación y sin documento acumulador.El mismo precio de slug. Ni la clave ni la base de datos añaden una línea.Nada en el libro mayor de hosting. cost.mjs devuelve null para is_xucode, y los tres slugs de xucode tienen precio 0, porque el plan ya cobró.
Qué tamaños puede elegirLos 17, desde shared_vps_05 hasta large_vps_32.Compartido no. El servidor rechaza cualquier slug cuyo tipo sea shared con el mensaje The shared server type is not available for a Full Stack VPS, mientras que el selector todavía muestra shared_managed_4 y shared_managed_8.Ningún selector. El slug se lee del derecho de uso, y todo lo que quien llama haya enviado sobre el tamaño se descarta en lugar de fusionarse.
Quién puede crear unoCualquier cuenta. deploy_vps no lleva min_plan, a diferencia de deploy_datacenter, que es clearance admin con min_plan pro.Tampoco lleva min_plan, pero el rechazo de compartido mencionado arriba es un mínimo con otro nombre.Condicionado a xucode.enabled, que es true en config_dev.json y false en config.json.
FirewallNinguno aplicado. proxmox_apply_firewall retorna de inmediato y el documento de firewall de la aplicación se crea con arreglos de reglas vacíos y la aplicación desactivada.Lo mismo. La clave acotada restringe lo que el equipo puede invocar de vuelta en Xuda, no lo que puede llegar al equipo.La única excepción: _xucode_sync_guard registra una protección de host para la dirección del equipo mediante fw_xucode_guard_set, y hay que volver a aplicar el firewall del host para que surta efecto.
Ubicación

Elegir una región acota dos listas. No elige un proveedor, y no elige un equipo.

El control de región no es un selector de centro de datos. MACRO_REGIONS en deploy_module contiene cinco claves, africa, apac, na, latam y emea, y cada una lleva un arreglo farm_locations de códigos de metrópoli, un arreglo de prefijos de slug de DigitalOcean y una coordenada representativa. Elegir una región limita el grupo de candidatos a esos códigos y siembra el ordenamiento por distancia con esa coordenada. Todo lo que viene después es aritmética sobre la capacidad real de los nodos, en el orden de abajo, y el último paso es el que conviene conocer antes de comprometerse: cuando el grupo acotado vuelve vacío, el despliegue se rechaza en lugar de moverse en silencio.

  • La región es un par de listas. apac nombra sin, blr y syd; na nombra ash, hil, sea, nyc, sfo y tor; emea nombra hel, fsn, nbg, ams, lon y fra. Eso son 15 de los 15 códigos de metrópoli de FARM_LOCATIONS. africa y latam no nombran ninguna ubicación de granja ni ningún prefijo propio de DigitalOcean, así que su grupo de candidatos está vacío por construcción y no por carga.
  • Cada candidato se mide contra su tamaño más un 20 por ciento. La ubicación multiplica los cores, la RAM y el disco solicitados por 1 + proxmox.headroom_pct/100, y config.json fija headroom_pct en 20. Un optimized_vps_4 con 4 vCPU, 16 GB y 100 GB necesita por tanto 4.8 cores libres, 19.2 GB libres de RAM y 120 GB libres de disco en un nodo antes de que ese nodo sea siquiera elegible.
  • Luego la clase de disco, y luego la distancia. SERVER_TYPE_DISK_PREF limita performance y large a solo nvme, optimized a ssd y luego nvme, y shared a hdd, ssd y luego nvme. Los nodos de la granja sin etiqueta cuentan como nvme, así que en la flota tal como está todos los tipos aterrizan en NVMe. Los supervivientes se ordenan por distancia de círculo máximo desde la coordenada de la región, así que gana el nodo más cercano que encaje.
  • Una región llena se responde, no se rodea. proxmox.do_failover es false, así que get_region_hosting_options devuelve provider farm o provider unavailable con reason no_capacity cuando la región tiene metrópolis pero no espacio, y no_farm_region para africa y latam. DigitalOcean nunca se sustituye automáticamente a sus espaldas: solo es accesible mediante una fijación explícita o desde la lista completa de opciones.
En qué se traduce una región
Claves de macrorregión
5
africa, apac, na, latam, emea
Metrópolis de granja que nombran entre todas
15
apac 3, na 6, emea 6
Regiones que no nombran ninguna metrópoli de granja
2
africa y latam, rechazadas estructuralmente
Holgura exigida por encima de su tamaño
20%
cores, RAM y disco, los tres
La barra de progreso

Se declaran siete pasos. Uno de ellos se ejecuta.

config.json declara job_steps en deploy_vps, y register_job guarda ese arreglo tal cual con current_step 1 y total_steps 7. Esas siete cadenas son el texto literal de la barra de progreso que un cliente ve durante un despliegue. En la vía de la granja la creación es farm_create_app, y no emite ninguna actualización de trabajo: el único update_job de toda la creación del VPS está en deploy_vps, antes de que se ceda el aprovisionamiento. Las dos columnas de abajo responden a las mismas siete filas en el mismo orden, la declaración a la izquierda y el código a la derecha, porque la distancia entre ambos es justamente el punto.

http_module lleva una segunda lista de repliegue de cinco cadenas para deploy_vps, usada solo cuando la configuración no declara ninguna. config.json declara siete, así que ese repliegue nunca se dispara. En lo que coinciden ambas vías es en el resultado: la VM está en marcha. En lo que discrepan es en todo lo que la barra decía que estaba ocurriendo mientras usted esperaba.
Lo que recibe

Tres direcciones, y solo dos de ellas son suyas para escribir.

Un VPS de granja sin IPv4 dedicada no tiene ninguna IPv4 pública. Tiene una dirección interna de VNet en su nodo, una /24 por nodo, más una IPv6 pública cuando ese nodo lleva una /64 enrutada. La accesibilidad se construye en lugar de darse por supuesta: en la primera activación, la plataforma aprovisiona una ruta de proxy inverso en un nombre de host <sub>.xuda.app para el navegador, y un túnel WebSocket al puerto 22 para la consola. Una IPv4 dedicada no tiene plan mínimo y solo depende de que haya capacidad libre en el nodo; si ningún nodo puede atenderla, la solicitud se elimina y el despliegue continúa con el nombre de host compartido en lugar de fallar.

https://vps<32 hex>.xuda.app/
app_hosting_server.ip 10.10.1.x dirección interna de VNet, una /24 por nodo, no enrutable desde su equipo
ipv6 porción /64 pública presente solo cuando el nodo lleva una /64 enrutada
una IPv4 pública dedicada cuesta $2.50 al mes más $10 de alta única, y solo si el nodo tiene una libre
https://vps<32 hex>.xuda.app/ con proxy inverso al puerto 80 de su VM
el subdominio es el id de la aplicación en minúsculas, prefijo vps más 32 hex, así que no puede colisionar. El puerto es configurable.
brew install websocat
websocat -b -E tcp-l:127.0.0.1:2222 wss://vps<32 hex>.xuda.app/__xuda_ssh -H "Authorization: Bearer YOUR_CONNECTION_TOKEN"
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=ERROR -p 2222 [email protected]
sftp viaja por el mismo túnel y el mismo puerto, que es adonde apuntan FileZilla y WinSCP
el token se muestra una sola vez y se guarda solo como hash sha256, así que uno perdido se rota, nunca se recupera
lo que responde en el puerto 22 es la imagen de nube estándar más las claves que usted suministró. No se instaló nada más.
Las dos líneas de comando largas son lo que el panel imprime para macOS, con su propio host y token sustituidos. 127.0.0.1:2222 queda excluido de known_hosts a propósito: ese puerto se asigna a una VM distinta por aplicación y por sesión, así que fijar su clave de host fallaría por completo en el siguiente equipo.
Tres movimientos

Región, tamaño, y a partir de ahí la máquina es suya.

deploy_vps no lleva min_plan, así que cualquier cuenta, incluida una gratuita, puede crear un VPS, y deploy_datacenter, justo al lado, es clearance admin con min_plan pro. La membresía no cambia ninguno de los precios: member_price_id existe solo en los planes ai_workspace, y ningún slug de servidor lleva un id de precio de Stripe ni una tarifa de miembro. El hosting se mide en lugar de suscribirse, prorrateado contra un mes fijo de 730.5 horas con un segmento facturable mínimo de una hora.

  1. 01

    Elija una región y un tamaño

    La escala de VPS son 17 slugs en cuatro tipos: shared desde 1 vCPU, 0.5 GB y 10 GB por $2.50 hasta 8 vCPU, 16 GB y 320 GB por $94; optimized de $66 a $542; performance de $166 a $1006 y hasta 32 vCPU, 256 GB y 800 GB por $1342; large de $650 hasta 32 vCPU, 256 GB y 7200 GB por $2606. El tipo no es una etiqueta de marketing, es la cadena de clases de disco que respetará la ubicación. La lista de SO son cinco imágenes: Ubuntu 24.04 LTS, Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9 y AlmaLinux 9. No hay marketplace en la granja ni catálogo de aplicaciones de un clic.

  2. 02

    La VM se clona y arranca

    Un plan se copia tal cual, no se interpreta: slug_to_farm_spec devuelve cores, ram_gb y disk_gb a partir del slug, la creación clona una plantilla con full: 1 de modo que es una máquina QEMU completa y no un contenedor ni un clon enlazado, fija cores, fija memory en ram_gb por 1024 MB, redimensiona scsi0 a disk_gb y la arranca. En cuanto la VM figura como running, la aplicación se marca como activa, porque para un VPS puro no queda nada que esperar. deploy_module realiza 84 llamadas a rutas /qemu/ y cero a /lxc/.

  3. 03

    Tómelo por la ruta web y el túnel

    El nombre de host para el navegador y el acceso SSH sobre WebSocket se garantizan durante la creación, así que el equipo es accesible antes de que usted haya configurado nada en él. A partir de ahí es suyo en sentido literal: la plataforma no aplica ningún firewall de VM a un VPS puro, no inicia sesión y no instala nada. Dos límites que conviene prever. El redimensionado es sin conexión y el disco solo crece, así que farm_resize_app rechaza la operación salvo que la VM figure como stopped, toma el mayor entre el disco actual y el solicitado, y deja que el sistema de archivos del invitado crezca en el arranque que usted realice. Y el almacenamiento en bloque, aunque está publicado, está desactivado: proxmox.block_storage.nfs_mount está vacío en ambas configuraciones, así que todos los métodos de volumen responden que el almacenamiento en bloque no está configurado.

Límites honestos

Nueve cosas que un VPS de Xuda no hace, cuatro de ellas prometidas por la interfaz que lo rodea.

  • No se instala nada en él. farm_create_app marca un VPS como activo en cuanto la VM informa running, y la rama de instalación bajo eso está condicionada por if (_conf.is_debug && !isVpsApp), así que en un equipo de cliente nunca se ejecuta. Lo que arranca es la imagen de nube limpia con las claves SSH que usted suministró. cpi/deploy_module/index.mjs líneas 13621 a 13641.
  • La plataforma no le aplica ningún firewall. proxmox_apply_firewall retorna de inmediato con la cadena vps: customer-managed firewall en las líneas 12369 a 12372, y el documento de firewall por aplicación que se escribe después lleva arreglos de reglas inbound y outbound vacíos con la aplicación desactivada, en cpi/firewall_module/index.mjs líneas 551 a 596. Cerrar puertos es tarea suya, y nada en el equipo lo hace por usted.
  • El almacenamiento en bloque está publicado y desactivado. proxmox.block_storage.nfs_mount es una cadena vacía tanto en config.json como en config_dev.json, así que los seis métodos farm_volume_, create attach detach resize list delete, responden que el almacenamiento en bloque no está configurado. index.mjs línea 14022. Su disco es el que lleve el slug más lo que usted lo haga crecer.
  • El selector del Full Stack VPS y el servidor no coinciden. Power.vue línea 219 lista el grupo managed menos sus dos entradas más pequeñas, lo que deja shared_managed_4 y shared_managed_8 como seleccionables, e index.mjs línea 1748 rechaza cualquier slug cuyo tipo sea shared con The shared server type is not available for a Full Stack VPS. config.json tampoco lleva ningún bloque full_stack_vps: los 13 grupos de herramientas y los 81 métodos viven solo en config_dev.json, así que en la configuración de producción esa clave se expande a una lista de permitidos vacía.
  • Los 58 slugs se resuelven a 29 ids de proveedor distintos, y 16 de esos ids los llevan más de un slug. lookup_server_info prueba primero la clave, luego busca por .id y devuelve la primera coincidencia, cost.mjs líneas 46 a 54. Para 12 de los 16, la primera entrada del archivo es la del grupo deployment, así que un documento heredado que guardó gd-2vcpu-8gb en lugar de optimized_vps_2 factura $73 al mes por una máquina listada en $66.
  • Los seis slugs service_hosting_, basic cpu general compute balanced memory, llevan todos disk 50 y se cobran de $24 a $129 puramente por CPU y RAM. Son equipos del grupo deployment para servicios cuyos datos viven en el centro de datos, y no se ofrecen en absoluto en el flujo de VPS. config.json líneas 938 a 991.
  • Los job_steps declarados para deploy_vps prometen setting vps firewall, setting vps backup plan, connecting to vps server, installing vps resources y activating the server. farm_create_app no emite ninguna actualización de progreso propia, así que en la vía de la granja solo aparece creating vps server. Los cuatro pasos posteriores son declaración, no trabajo.
  • La lista de características de vps en la configuración afirma SSD-Based Servers, 1-Click App Install y Managed Backups. La preferencia de disco de shared es hdd, luego ssd, luego nvme; la granja ofrece cinco imágenes de SO y ningún marketplace; y las copias de seguridad son un complemento opcional de $10 al mes. config.json líneas 781 a 791.
  • app_server_type es mandatory: false en deploy_vps. Un despliegue global sin slug aprovisiona el mínimo de 1 vCPU, 0.5 GB y 10 GB, no escribe ningún app_cost, y is_billable devuelve entonces false, así que la máquina funciona y no factura nada. La comprobación de saldo que lo habría detectado, validate_account_topup, está comentada en index.mjs línea 1480.
Antes de desplegar

Las seis preguntas que la tabla de precios no responde

Respondidas contra el código publicado y las claves de configuración que lo deciden, incluso donde la respuesta es no.

Vea

Vea cómo un clon se convierte en una máquina en marcha.

Un clon completo de la VM plantilla, con los cores y la memoria escritos sobre la copia, scsi0 redimensionado al disco del slug, y luego el estado pasando a activo en el instante en que la VM informa running. Lo interesante es lo que no ocurre después: sin paso de instalación, sin agente, sin conjunto de reglas. Lo que arranca es la imagen de SO que usted eligió con las claves que usted le dio.

Elija un slug y una región, y el ubicador elige el equipo.

Diecisiete slugs, desde 1 vCPU, 0.5 GB y 10 GB por $2.50 al mes hasta 32 vCPU, 256 GB y 7200 GB por $2606, cada uno de ellos una máquina virtual QEMU completa clonada con full: 1 y no un contenedor. La región que elige es una clave macro, no un proveedor ni una máquina: la ubicación conserva los nodos de la granja que superan sus cores, RAM y disco más un 20 por ciento de holgura, ordena a los supervivientes por distancia de círculo máximo y toma el más cercano. Si una región no tiene espacio, la respuesta es no_capacity, no un traslado silencioso a DigitalOcean, porque do_failover es false. La facturación corre por medidor desde la hora en que arranca.