Sesgo declarado, como siempre: enseño Claude Code a equipos de ingeniería, así que dónde se ejecuta el código de tu empresa me toca de lleno. Precisamente por eso esta pieza va de hechos verificables y de qué te toca decidir, no de vender una feature de infraestructura como si cambiara el día a día de todo el mundo: no lo hace. Pero para una parte concreta de los equipos, cambia algo que hasta ahora era un "no" rotundo.
Los hechos
El 7 de agosto de 2026, la versión 2.1.224 de Claude Code añadió,
según el changelog oficial, los
entornos self-hosted: el comando claude self-hosted-runner "convierte tus
propias máquinas o contenedores en un lugar donde pueden ejecutarse las sesiones
web, móvil y de escritorio de Claude Code, en los planes Team y Enterprise".
Según la documentación de entornos self-hosted, la feature está en beta pública para Team y Enterprise y viene desactivada por defecto: un Owner o admin tiene que activar Allow self-hosted environments en la página de administración de Cloud environments, y para ello la organización necesita tener habilitado Claude Code en la web.
Conviene fijar bien de qué hablamos, porque el nombre despista. Una sesión
cloud es cualquier sesión que corre en un sitio que no es la máquina del
desarrollador: las que arrancas desde claude.ai, desde las apps de móvil y
escritorio, desde la terminal con claude --cloud, y las
rutinas programadas. Por defecto,
todas ellas se ejecutan en la infraestructura de Anthropic. Lo que hace un
entorno self-hosted es que esas mismas sesiones se ejecuten dentro de tu red,
sin cambiar la experiencia del desarrollador.
Un detalle que ahorra confusiones: si tu equipo no usa sesiones cloud, aquí no hay nada que configurar. Las sesiones en terminal o en el IDE siempre corren en la máquina del desarrollador. Esto va solo de las sesiones que, hasta ahora, salían a la nube de Anthropic.
Cómo funciona, en tres piezas
La documentación lo estructura en tres conceptos, y merece la pena entenderlos antes de decidir nada:
- Environment (entorno): un destino con nombre al que se pueden enviar sesiones. Se crea en los ajustes de administración de claude.ai y agrupa un conjunto de runners.
- Runner: un programa que corre en máquinas de tu red y que ejecuta las sesiones. La analogía es la de un runner de CI self-hosted: el mismo modelo mental que ya usas si alojas tus propios runners de GitHub Actions.
- Session (sesión): una tarea concreta que arranca un desarrollador.
El flujo es directo: cuando alguien arranca una sesión cloud, el selector de
entorno le muestra los de Anthropic junto a los que haya creado tu
organización. Si elige el tuyo, el plano de control de Anthropic coloca la
sesión en la cola de tu entorno, un runner la reclama, clona el repositorio y
lanza un proceso de Claude Code en tu máquina para ejecutarla. Todo el
tráfico hacia Anthropic —sondeo de la cola, flujo de eventos e inferencia del
modelo— es HTTPS de salida hacia api.anthropic.com; la documentación es
explícita en que Anthropic nunca se conecta hacia dentro de tu red.
Qué se queda en tu red y qué no (léelo antes de venderlo internamente)
Aquí está la parte que no puedes saltarte si vas a defender esto ante seguridad, porque es fácil sobrevender el "self-hosted".
Lo que se queda en tu infraestructura: los checkouts del repositorio, los artefactos de build, los secretos y cualquier fichero que la sesión cree o modifique se quedan en las máquinas que tú provisiones.
Lo que sigue saliendo a Anthropic: la conversación en sí —prompts,
respuestas y resultados de herramientas— va a api.anthropic.com para la
inferencia del modelo, y el transcript de la sesión lo almacena Anthropic
para que puedas retomarla desde cualquier superficie. La orquestación de
sesiones, la cola y la interfaz de claude.ai siguen siendo de Anthropic: un
entorno self-hosted mueve la ejecución de la sesión a tu red, no el plano de
control.
Dicho de otra forma: self-hosting resuelve dónde se ejecuta y se clona tu código, no elimina que el contenido de la conversación pase por la API de Anthropic. Para muchos requisitos de cumplimiento eso es exactamente lo que hace falta; para otros, no. Sabérselo de memoria antes de la reunión evita un "pero entonces esto no era lo que dijiste".
Y hay una contrapartida operativa clara: la propiedad se mueve a ti. La documentación lo dice sin rodeos —construyes y mantienes la imagen del runner, operas la flota y controlas su red— y el aislamiento entre sesiones es responsabilidad de tu despliegue. Esto no es "enciende un flag"; es asumir un componente de infraestructura.
Qué te afecta, según quién seas
Si administras Claude Code para un equipo con red o cumplimiento estrictos.
Esta es la novedad que te toca. Hasta ahora, si la política de tu empresa impedía
que el código saliera a una nube de terceros, las sesiones cloud —y con ellas
Claude Code en la web, las rutinas y claude --cloud— eran directamente
inviables. Ahora puedes ejecutarlas dentro de tu red, con las sesiones
alcanzando tus servicios internos, bases de datos y registries sin exponerlos a
internet, y con tu tooling (compiladores, SDKs, CLIs internas) preinstalado en la
imagen del runner. A cambio, asumes operar la flota. Decidir si ese intercambio
compensa, y bajo qué política de permisos y settings gestionados, es justo el
tipo de criterio que trabajamos en el curso de
permisos, settings y seguridad.
Si tu organización tiene lista de IPs permitidas (IP allowlisting). Aquí hay un efecto muy concreto. Según la documentación de Claude Code en la web, con IP allowlisting activado toda sesión cloud alojada en Anthropic falla con un error de autenticación, porque llama a la API desde infraestructura de Anthropic y no desde tu red. Una sesión en un entorno self-hosted, en cambio, llama a la API desde tu propia red. Si te habías topado con ese muro, esta es la vía para sortearlo sin pedir excepciones a Anthropic.
Si montas automatización y CI alrededor de Claude Code. El modelo de runner te va a resultar familiar, y no es casualidad: es el mismo patrón que un runner de CI self-hosted. Las sesiones se pueden despachar también de forma scriptada a un entorno concreto, y hay un smoke test de extremo a extremo para verificar la imagen del runner antes de promocionarla. Si ya piensas en Claude Code como una pieza más de tu pipeline, encaja con lo que vemos en el curso de CI, GitHub Actions y code review.
Si tu organización tiene Zero Data Retention. Malas noticias por ahora: los entornos self-hosted no están disponibles para organizaciones con Zero Data Retention activado. Tampoco puedes enrutar la inferencia por Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry ni un gateway LLM: las sesiones usan la API de Anthropic. Y algunas superficies —Claude Tag, Claude Security y Code Review— aún no se enrutan a estos entornos; el soporte llega por separado.
Si tu equipo no usa sesiones cloud. No te afecta. Las sesiones en terminal y en el IDE siempre han corrido y seguirán corriendo en la máquina del desarrollador. Si lo que quieres es tener Claude Code en una máquina siempre encendida y pilotarlo desde otros dispositivos, eso es Remote Control, que además está en Pro y Max, y no tiene nada que ver con esto.
Qué llevarte
claude self-hosted-runner(v2.1.224, 7 de agosto de 2026): ejecuta las sesiones cloud de Claude Code (web, móvil, escritorio, terminal y rutinas) dentro de tu red. Beta pública en Team y Enterprise, desactivado por defecto; lo activa un Owner/admin.- Tres piezas: entorno (destino con nombre) → runner (proceso en tus máquinas, como un runner de CI self-hosted) → sesión. Todo el tráfico es HTTPS de salida; Anthropic no entra en tu red.
- Se queda en tu infra: checkouts, artefactos, secretos y ficheros. Sigue saliendo a Anthropic: el contenido de la conversación, para la inferencia, y el transcript, que almacena Anthropic. El plano de control es de Anthropic.
- Asumes la operación: imagen del runner, flota y red; el aislamiento entre sesiones es responsabilidad de tu despliegue.
- Exclusiones a día de hoy: nada de Zero Data Retention, ni inferencia por Bedrock/Agent Platform/Foundry o gateway LLM; Claude Tag, Claude Security y Code Review aún no se enrutan.
Preguntas rápidas
¿Esto quiere decir que mi código ya no sale a Anthropic?
No del todo, y conviene ser preciso. Los checkouts del repositorio, los artefactos
y los secretos se quedan en tu infraestructura, pero el contenido de la
conversación (prompts, respuestas y resultados de herramientas) va a
api.anthropic.com para la inferencia y el transcript lo almacena Anthropic. Lo
que se mueve a tu red es la ejecución de la sesión, no el plano de control.
¿Necesito montar esto para usar Claude Code en el día a día?
No. Las sesiones de terminal e IDE corren siempre en tu máquina y no requieren
nada de esto. Los entornos self-hosted solo entran en juego si tu equipo usa
sesiones cloud (web, claude --cloud, rutinas, apps) y quiere ejecutarlas en su
propia infraestructura.
Teníamos IP allowlisting y las sesiones cloud fallaban, ¿esto lo arregla? Esa es una de las razones de más peso para mirarlo. Las sesiones alojadas en Anthropic fallan con IP allowlisting porque llaman a la API desde infraestructura de Anthropic; una sesión self-hosted la llama desde tu red.
¿Es estable? Es beta pública en Team y Enterprise. Léelo como lo que es: disponible para probar y desplegar con criterio, no como comportamiento asentado. Empieza por la documentación oficial antes de planear un despliegue.
¿Estáis valorando ejecutar Claude Code dentro de vuestra propia red? Decidir si el intercambio compensa —qué se queda en vuestra infraestructura, qué sigue pasando por la API, y bajo qué política de permisos y settings gestionados desplegarlo— es exactamente el tipo de criterio que trabajamos en la formación en directo para equipos, sobre vuestro repo, vuestra red y vuestros requisitos reales de cumplimiento.