Todo el stack, en tus propios servidores
Ejecuta DialPress donde tus datos tengan que estar. Empieza con un servidor Linux, pasa a contenedores y crece hacia Kubernetes, con las mismas apps y rutas en cada paso.
De un vistazo
Tus datos
Las llamadas, grabaciones y transcripciones se quedan en infraestructura que tú controlas.
El mismo código
Las apps y las rutas no cambian entre DialPress cloud y tus servidores.
Por módulo
Añade capacidad donde está la carga, no en todas partes a la vez.
Sin cortes
Las instancias que se detienen se vacían primero, así las actualizaciones nunca cortan a un llamante.
Desplegar
Elige dónde se ejecuta
Cada paso usa los mismos módulos. Sube de nivel cuando la carga lo pida.
- Step 1
DialPress cloud
Empieza en nuestra nube. Números, operadores y voz incluidos.
$ export DP=https://api.dialpress.ai/v1 $ curl -X POST $DP/agents/front-desk/calls \ -H "Authorization: Bearer $TOKEN" \ -d '{"to": "+15550100", "from": "+15550199"}' { "id": "c_8f2c", "state": "initiating" } $ curl "$DP/calls/c_8f2c?wait=answered&timeout=30s" { "id": "c_8f2c", "state": "answered" } - Step 2
Un servidor Linux
Un único instalador configura el gateway, la voz y los agentes como servicios systemd reforzados, con TLS para tu dominio.
# hardened systemd units, TLS for your domain $ deploy/linux/install.sh install --build \ --domain voice.yourcompany.com --email [email protected] ✓ dialpress ✓ dialpress-speech ✓ dialpress-agents # or every module as a container $ docker compose -f docker-compose.yml \ -f docker-compose.modules.yml up -d --wait - Step 3
Kubernetes
Un chart de Helm ejecuta cada módulo como su propia carga de trabajo y lo autoescala según métricas en vivo. Los pods que se detienen se vacían primero, así los despliegues nunca cortan una llamada.
$ helm upgrade --install dialpress deploy/helm/dialpress \ -f deploy/helm/dialpress/values-production.yaml Release "dialpress" has been upgraded. Happy Helming! $ kubectl get deploy -n dialpress dialpress 3/3 dialpress-api 2/2 dialpress-speech 4/4 dialpress-agents 3/3 - Step 4
Máquinas con GPU
La voz y los agentes se ejecutan en máquinas con GPU con TLS mutuo, balanceados por modelo y carga.
# balanced by model and load, over mutual TLS $ export DIALPRESS_SPEECH_RECOGNITION_BALANCED=true $ export DIALPRESS_SPEECH_RECOGNITION_ENDPOINTS=\ gpu1.example.com:7071;models=whisper-small;weight=2,\ gpu2.example.com:7071;models=whisper-small|parakeet $ dialpress ✓ speech-recognition: 2 endpoints healthy
Hecho para escalar
Cada capa escala por su cuenta.
01
Modular por diseño
Cada módulo (gateway, voz, agentes, mensajería, grabación) se ejecuta en el mismo proceso, como proceso propio o en sus propias máquinas con TLS mutuo.
02
Gateways horizontales
Ejecuta tantas instancias de gateway como necesites. Los registros se comparten, las llamadas mantienen la afinidad de diálogo y el tráfico se reparte según una política.
03
Voz balanceada entre GPUs
Las solicitudes de voz y de agentes van al endpoint sano con menos carga que sirve el modelo, ponderado por GPU.
04
Autoescalado
En Kubernetes, cada grupo de módulos escala según métricas en vivo y CPU, con los límites que fijes para cada módulo.
05
Despliegues sin cortes
Las instancias que se detienen se vacían primero: sin llamadas nuevas, las activas terminan. Las actualizaciones y reducciones nunca cortan a un llamante.
06
Mismo código, cualquier tamaño
Un binario en un portátil, un stack de Compose en un VPS o una flota en Kubernetes. Tus apps y rutas no cambian.
Preguntas frecuentes
¿Por qué autoalojar?
Residencia de datos, control sobre modelos y GPUs, y un coste predecible a gran volumen.
¿Qué necesito para empezar?
Un servidor Linux y un dominio. El instalador configura TLS.
¿Puede la voz ejecutarse en máquinas separadas?
Sí. La voz y los agentes se ejecutan en máquinas con GPU con TLS mutuo.
¿Cuál es el precio del autoalojamiento?
Los despliegues autoalojados se cotizan con un acuerdo enterprise.
Ejecuta DialPress en tus servidores.
Cuéntanos dónde tiene que ejecutarse y un ingeniero te ayudará a dimensionarlo.