HassleFree.tech — Kubernetes PaaS for AI-Driven Teams

◆ Core Concepts◆ Conceptos Clave

Six building blocks,
infinite possibilities Seis piezas fundamentales,
posibilidades infinitas

HassleFree organizes your infrastructure into simple, composable primitives. Learn these six concepts and you can build anything. HassleFree organiza tu infraestructura en primitivas simples y componibles. Aprende estos seis conceptos y podrás construir cualquier cosa.

📦

ProjectsProyectos

A Project is your top-level container — a Kubernetes namespace paired with a dedicated subdomain and its own NGINX reverse proxy. All services, variables, build plans, and workflows live inside a project. Each project is fully isolated. Un Proyecto es tu contenedor de nivel superior — un namespace de Kubernetes emparejado con un subdominio dedicado y su propio proxy inverso NGINX. Todos los servicios, variables, planes de build y workflows viven dentro de un proyecto. Cada proyecto está completamente aislado.

K8s namespace + domain + NGINX

🖼️

ImagesImágenes

Images are your container registry entries. Each image tracks multiple versions with tags, digests, and build metadata. Images can come from HassleFree builds or be registered from external registries. Services reference images by name. Las Imágenes son tus entradas en el registro de contenedores. Cada imagen rastrea múltiples versiones con tags, digests y metadatos de build. Las imágenes pueden provenir de builds de HassleFree o registrarse desde registros externos. Los servicios referencian imágenes por nombre.

registry + versions + tags

🏗️

Build PlansPlanes de Build

Build Plans define how to turn source code into container images. They specify the Git repo, Dockerfile path, build arguments, config file injection, and auto-versioning format. Builds download source via Git (commit SHA > tag > branch priority), run multi-stage Dockerfiles, and push to the private registry. Los Planes de Build definen cómo convertir código fuente en imágenes de contenedor. Especifican el repo Git, ruta del Dockerfile, argumentos de build, inyección de archivos de configuración y formato de auto-versionado. Los builds descargan código vía Git (prioridad: SHA > tag > rama), ejecutan Dockerfiles multi-etapa y suben al registro privado.

git → dockerfile → registry

🚀

ServicesServicios

Services are running containers on Kubernetes. Configure replicas, health checks, resource limits, environment variables, persistent volumes, sidecar containers, and exposure mode (proxied, public, or internal). Deploy-time variable substitution injects secrets at the moment of deployment. Los Servicios son contenedores ejecutándose en Kubernetes. Configura réplicas, health checks, límites de recursos, variables de entorno, volúmenes persistentes, contenedores sidecar y modo de exposición (proxy, público o interno). La sustitución de variables en tiempo de despliegue inyecta secretos al momento del despliegue.

K8s deployment + service + config

🔄

WorkflowsWorkflows

Workflows are multi-step CI/CD pipelines with dependency graphs (DAGs). Step types include BUILD, SERVICE_UPDATE, SERVICE_DEPLOY, WEBHOOK, and CUSTOM. Steps without dependencies run in parallel. Each step outputs namespaced variables that downstream steps can reference. Los Workflows son pipelines CI/CD de múltiples pasos con grafos de dependencias (DAGs). Los tipos de paso incluyen BUILD, SERVICE_UPDATE, SERVICE_DEPLOY, WEBHOOK y CUSTOM. Los pasos sin dependencias se ejecutan en paralelo. Cada paso exporta variables con namespace que los pasos posteriores pueden referenciar.

DAG pipeline + step variables

🪝

Webhooks

Webhooks connect your Git provider to HassleFree. They auto-register endpoints, parse push/tag/PR/comment events, extract commit SHA and branch into variables, and trigger workflows based on configurable branch patterns. Build status is reported back to the Git provider. Los Webhooks conectan tu proveedor Git con HassleFree. Auto-registran endpoints, parsean eventos push/tag/PR/comentario, extraen el SHA del commit y la rama en variables, y disparan workflows según patrones de rama configurables. El estado del build se reporta de vuelta al proveedor Git.

git events → workflow triggers

⬡ Platform⬡ Plataforma

Everything you need to ship,
nothing you don't Todo lo que necesitas para desplegar,
nada que no

From Git push to production. Build images, deploy services, manage SSL, run workflows — all from one platform. Desde git push hasta producción. Construye imágenes, despliega servicios, gestiona SSL, ejecuta workflows — todo desde una plataforma.

📦

Container BuildsBuilds de Contenedores

Multi-stage Dockerfiles with build args and config file injection. Git source is downloaded with commit SHA priority (SHA > tag > branch). Build status is reported back to your Git provider with direct links. Dockerfiles multi-etapa con argumentos de build e inyección de archivos de configuración. El código se descarga con prioridad de SHA de commit (SHA > tag > rama). El estado del build se reporta a tu proveedor Git con enlaces directos.

🚀

One-Click DeployDespliegue en un Clic

Deploy services with replicas, health checks, rolling updates, and persistent volumes. Zero-downtime deployments by default. Config files and secrets injected at deploy time via variable substitution. Despliega servicios con réplicas, health checks, actualizaciones rolling y volúmenes persistentes. Despliegues sin downtime por defecto. Archivos de configuración y secretos inyectados en tiempo de despliegue vía sustitución de variables.

🔄

CI/CD WorkflowsWorkflows CI/CD

Multi-step DAG pipelines with 5 step types. Steps without dependencies execute in parallel. Trigger-agnostic: webhook, manual, scheduled, or cross-workflow. Step-namespaced variables flow downstream automatically. Pipelines DAG multi-paso con 5 tipos de paso. Los pasos sin dependencias se ejecutan en paralelo. Agnóstico al trigger: webhook, manual, programado o cross-workflow. Las variables con namespace fluyen automáticamente.

🔒

Auto SSLSSL Automático

Wildcard certificates for default subdomains (instant). Let's Encrypt ACME HTTP-01 for custom domains with auto-renewal 30 days before expiration. Certs stored as project variables and picked up via <<ssl.crt>> on service restart. Certificados wildcard para subdominios por defecto (instantáneo). Let's Encrypt ACME HTTP-01 para dominios personalizados con renovación automática 30 días antes del vencimiento. Certificados almacenados como variables de proyecto.

🌐

Smart RoutingEnrutamiento Inteligente

Per-project NGINX reverse proxy with path-based routing. Multiple services share one domain with different paths. Direct NodePort exposure for WebSocket and gRPC services. Internal ClusterIP for service-to-service communication. Proxy inverso NGINX por proyecto con enrutamiento basado en rutas. Múltiples servicios comparten un dominio con diferentes rutas. Exposición directa NodePort para WebSocket y gRPC. ClusterIP interno para comunicación entre servicios.

📋

Project TemplatesPlantillas de Proyecto

One-click scaffolding with variable substitution. Define reusable project structures with services, build plans, workflows, and variables. Template registries for sharing across teams. Git repos auto-created from templates. Scaffolding de un clic con sustitución de variables. Define estructuras de proyecto reutilizables con servicios, planes de build, workflows y variables. Registros de plantillas para compartir entre equipos. Repos Git auto-creados desde plantillas.

🏷️

Auto-VersioningAuto-Versionado

Configurable version format per build plan. Automatically increments on each build. Version is injected as a build argument and available as a step output variable. Tag images with semantic versions, dates, or custom patterns. Formato de versión configurable por plan de build. Se incrementa automáticamente en cada build. La versión se inyecta como argumento de build y está disponible como variable de salida. Etiqueta imágenes con versiones semánticas, fechas o patrones personalizados.

🔀

Variable SubstitutionSustitución de Variables

Five distinct variable syntaxes for five contexts: template-time, deploy-time, workflow-time, step outputs, and build references. The key differentiator — variables resolve at exactly the right moment in the pipeline. Cinco sintaxis distintas de variables para cinco contextos: tiempo de plantilla, tiempo de despliegue, tiempo de workflow, salidas de paso y referencias de build. El diferenciador clave — las variables se resuelven en el momento exacto del pipeline.

🧩

Sidecar ContainersContenedores Sidecar

Attach sidecar containers to any service for logging agents, proxies, or helper processes. Sidecars share the pod's network and volumes. Configure independently with their own images, ports, and environment variables. Adjunta contenedores sidecar a cualquier servicio para agentes de logging, proxies o procesos auxiliares. Los sidecars comparten la red y volúmenes del pod. Configúralos independientemente con sus propias imágenes, puertos y variables de entorno.

💾

Volume SnapshotsSnapshots de Volúmenes

Create point-in-time snapshots of persistent volumes for backup and cloning. Snapshots power ephemeral environments — clone production data for realistic testing without risking the original. Scheduled or on-demand. Crea snapshots puntuales de volúmenes persistentes para respaldo y clonación. Los snapshots impulsan los entornos efímeros — clona datos de producción para pruebas realistas sin riesgo. Programados o bajo demanda.

⏰

SchedulerProgramador

Cron-based scheduling for workflows, builds, and snapshots. Set recurring builds on a schedule, trigger cleanup workflows nightly, or automate snapshot creation. Full cron expression support with timezone awareness. Programación basada en cron para workflows, builds y snapshots. Configura builds recurrentes en un horario, dispara workflows de limpieza nocturnos, o automatiza creación de snapshots. Soporte completo de expresiones cron con zona horaria.

🔌

Plugin SystemSistema de Plugins

Extend HassleFree with plugins for custom integrations. Webhook step type allows calling external services during workflows. Custom step type runs arbitrary containers for testing, notifications, or any custom logic. Extiende HassleFree con plugins para integraciones personalizadas. El tipo de paso WEBHOOK permite llamar servicios externos durante workflows. El tipo CUSTOM ejecuta contenedores arbitrarios para pruebas, notificaciones o lógica personalizada.

👥

Role-Based AccessControl de Acceso por Roles

Five granular roles per project — Owner, Admin, Build, Deploy, Read. Assign roles per team member, per project. An engineer can be Owner on their project and Read-only on another. Permissions cascade logically. Cinco roles granulares por proyecto — Owner, Admin, Build, Deploy, Read. Asigna roles por miembro del equipo, por proyecto. Un ingeniero puede ser Owner en su proyecto y Read-only en otro. Los permisos se heredan lógicamente.

📡

Real-time EventsEventos en Tiempo Real

Socket.IO with Redis adapter for live build and deploy status streaming. Watch builds complete, services come online, and workflows progress — all in real time. No polling required. Socket.IO con adaptador Redis para streaming en vivo del estado de builds y deploys. Observa builds completarse, servicios activarse y workflows progresar — todo en tiempo real. Sin necesidad de polling.

→ Workflow→ Flujo de Trabajo

From git push
to production Desde git push
hasta producción

Webhooks catch your Git events, trigger multi-step workflows, build images, deploy services, and report back — all automatically. Los webhooks capturan tus eventos Git, disparan workflows multi-paso, construyen imágenes, despliegan servicios y reportan — todo automáticamente.

Git Push → WebhookGit Push → Webhook

Push to main, create a tag, or comment /deploy on a PR. HassleFree catches the event and extracts commit SHA, branch, and repo URL into variables. Haz push a main, crea un tag, o comenta /deploy en un PR. HassleFree captura el evento y extrae el SHA del commit, rama y URL del repo en variables.

Build Container ImageConstruir Imagen

Build plan pulls your code via Git (SHA > tag > branch), runs the multi-stage Dockerfile, pushes to the private registry. Auto-versioned with configurable format. El plan de build descarga tu código vía Git (SHA > tag > rama), ejecuta el Dockerfile multi-etapa, sube al registro privado. Auto-versionado con formato configurable.

Deploy to KubernetesDesplegar en Kubernetes

Rolling update with zero downtime. Config files, env vars, and AES-256 encrypted secrets injected at deploy time. The step uses ${build-api.IMAGE_VERSION} from the build step. Actualización rolling sin downtime. Archivos de config, env vars y secretos encriptados AES-256 inyectados en tiempo de despliegue. El paso usa ${build-api.IMAGE_VERSION} del paso de build.

Live on Your DomainEn Vivo en tu Dominio

SSL termination, load balancing, health checks — all handled. Build status reported back to Git. Your app is live at project.hasslefree.tech. Terminación SSL, balanceo de carga, health checks — todo gestionado. Estado del build reportado a Git. Tu app está en vivo en project.hasslefree.tech.

                        
                        
                        
                        workflow.json
                    

// Build two services in parallel, then deploy both
{
  "name": "full-deploy",
  "steps": [
    {
      "name": "build-api",
      "type": "BUILD",
      "config": {
        "buildPlanName": "api-plan"
      }
    },
    {
      "name": "build-web",
      "type": "BUILD",
      "config": {
        "buildPlanName": "web-plan"
      }
    },
    {
      "name": "deploy-api",
      "type": "SERVICE_UPDATE",
      "dependencies": ["build-api"],
      "config": {
        "serviceName": "api",
        "imageVersion": "${build-api.IMAGE_VERSION}"
      }
    },
    {
      "name": "deploy-web",
      "type": "SERVICE_UPDATE",
      "dependencies": ["build-web"],
      "config": {
        "serviceName": "web",
        "imageVersion": "${build-web.IMAGE_VERSION}"
      }
    },
    {
      "name": "notify",
      "type": "WEBHOOK",
      "dependencies": ["deploy-api", "deploy-web"],
      "config": {
        "url": "https://slack.com/webhook/...",
        "body": "Deployed v${build-api.IMAGE_VERSION}"
      }
    }
  ]
}
                    

🏗️ Build System🏗️ Sistema de Build

From source code
to container image Del código fuente
a imagen de contenedor

Build plans define the recipe. The build engine handles everything: Git checkout, Dockerfile generation, image push, version tagging, and status reporting — all with zero manual steps. Los planes de build definen la receta. El motor de builds maneja todo: checkout de Git, generación de Dockerfile, push de imagen, etiquetado de versión y reporte de estado — todo sin pasos manuales.

📥

Git Source PriorityPrioridad de Fuente Git

Code is fetched with strict priority: Commit SHA → Tag → Branch. SHA gives you exact, immutable builds. Dynamic references with @COMMIT_SHA pull values from webhook variables at trigger time. El código se obtiene con prioridad estricta: Commit SHA → Tag → Rama. SHA te da builds exactos e inmutables. Referencias dinámicas con @COMMIT_SHA toman valores de variables del webhook al momento del trigger.

🐳

Multi-Stage DockerfilesDockerfiles Multi-Etapa

Auto-generate multi-stage Dockerfiles from build plan config. Define base images, file copies, and compile commands. Build args and config files injected into the build context automatically. Auto-genera Dockerfiles multi-etapa desde la config del plan de build. Define imágenes base, copias de archivos y comandos de compilación. Args de build y archivos de config inyectados automáticamente.

🏷️

Auto-VersioningAuto-Versionado

Configurable semantic version format: major.minor.patch-build. Each build auto-increments the appropriate segment. Version is injected as a build arg and exported as a step output variable for downstream workflow steps. Formato de versión semántica configurable: major.minor.patch-build. Cada build auto-incrementa el segmento apropiado. La versión se inyecta como arg de build y se exporta como variable de salida.

📋

Sequential Build QueueCola de Build Secuencial

Builds are queued and processed sequentially per project to prevent resource contention. Supports cancellation, priority ordering, and real-time status streaming via Socket.IO. Los builds se encolan y procesan secuencialmente por proyecto para evitar contención de recursos. Soporta cancelación, priorización y streaming de estado en tiempo real vía Socket.IO.

✅

Git Status ReportingReporte de Estado Git

Build results are reported back to your Git provider as commit status checks (pending → success/failure). Team members see ✅ or ❌ on PRs with direct links to build logs. Los resultados del build se reportan a tu proveedor Git como checks de estado de commit (pendiente → éxito/fallo). Los miembros del equipo ven ✅ o ❌ en PRs con enlaces directos a logs.

                            
                            
                            
                            build-plan.json
                        

// Build plan with auto-versioning & config injection
{
  "name": "api-plan",
  "source": {
    "provider": "github",
    "repo": "org/api-service",
    "commit": "@COMMIT_SHA",
    "branch": "@BRANCH"
  },
  "dockerfile": "Dockerfile",
  "buildArgs": {
    "NODE_ENV": "production"
  },
  "configFiles": [
    {
      "source": "nginx.conf.template",
      "target": "nginx.conf"
    }
  ],
  "autoVersion": {
    "enabled": true,
    "format": "[major].[minor].[patch]-[build]"
  },
  "image": "api-service"
}

// Git source priority: SHA → Tag → Branch
// SHA = exact, immutable build
// Tag = named release point
// Branch = latest commit
                        

📥

CloneClonar

Git fetch
with authGit fetch
con auth

⚙️

InjectInyectar

Config files
& build argsArchivos config
& args de build

🐳

BuildConstruir

Multi-stage
DockerfileDockerfile
multi-etapa

📦

PushSubir

Private
registryRegistro
privado

✅

ReportReportar

Git status
+ versionEstado Git
+ versión

⟨⟩ Variable System⟨⟩ Sistema de Variables

Five syntaxes, five contexts,
one powerful system Cinco sintaxis, cinco contextos,
un sistema poderoso

HassleFree's variable substitution system is a key differentiator. Variables resolve at exactly the right moment — from template creation to runtime. No more leaking secrets in build layers or hardcoding values. El sistema de sustitución de variables de HassleFree es un diferenciador clave. Las variables se resuelven en el momento exacto — desde la creación de plantillas hasta el runtime. No más secretos expuestos en capas de build ni valores hardcodeados.

SyntaxSintaxis	NameNombre	When it resolvesCuándo se resuelve	ExampleEjemplo	Use caseCaso de uso
{{VAR}}	Template-timeTiempo de plantilla	When template is appliedAl aplicar la plantilla	`{{PROJECT_NAME}}`	Scaffolding new projects from templates. Values baked in once and never change. Scaffold de nuevos proyectos desde plantillas. Valores fijos que no cambian.
<<VAR>>	Deploy-timeTiempo de despliegue	At each deploymentEn cada despliegue	`<<DB_PASSWORD>>`	Injecting secrets and config that may change between deploys. Also supports `<<random(32)>>` for deployment-time random generation and `<<ssl.crt>>` for certificates. Inyectar secretos y config que pueden cambiar entre despliegues. También soporta `<<random(32)>>` para generación aleatoria y `<<ssl.crt>>` para certificados.
${VAR}	Workflow-timeTiempo de workflow	During workflow executionDurante ejecución del workflow	`${BRANCH}`	Passing webhook payload data (commit SHA, branch, repo URL) into workflow steps. Available to all steps. Pasar datos del payload del webhook (SHA, rama, URL del repo) a los pasos del workflow. Disponible para todos los pasos.
${step.VAR}	Step outputSalida de paso	After preceding step completesTras completar paso anterior	`${build-api.IMAGE_VERSION}`	Passing outputs between workflow steps. Each step's variables are namespaced by step name, enabling parallel builds to feed into deploy steps. Pasar outputs entre pasos del workflow. Las variables de cada paso tienen namespace por nombre de paso, permitiendo que builds paralelos alimenten pasos de deploy.
@VAR	Build referenceReferencia de build	At build configurationEn configuración de build	`@IMAGE_NAME`	Referencing build plan properties like image name, version format, or registry path within build configurations. Referenciar propiedades del plan de build como nombre de imagen, formato de versión o ruta del registro dentro de configuraciones de build.

                        
                            variable-flow-example.md
                            ejemplo-flujo-variables.md
                        
// ─── Variable resolution flow ───

// 1. Template-time: when project is created from template
service.name = "{{PROJECT_NAME}}-api"  → "my-app-api"

// 2. Build-time: build plan uses @refs
image = "registry.local/@IMAGE_NAME:@VERSION"

// 3. Workflow-time: webhook injects variables
branch = "${BRANCH}"  → "main"
commit = "${COMMIT_SHA}"  → "a1b2c3d"

// 4. Step output: build step exports version
imageVersion = "${build-api.IMAGE_VERSION}"  → "1.4.2"

// 5. Deploy-time: secrets injected at deployment
DB_PASSWORD = "<<DB_PASSWORD>>"  → "s3cur3_p@ss"
SESSION_KEY = "<<random(64)>>"  → "a7f2...9e3b"
TLS_CERT    = "<<ssl.crt>>"    → (PEM certificate)

🌐 Service Exposure🌐 Exposición de Servicios

Three ways to expose
your services Tres formas de exponer
tus servicios

Choose the right exposure pattern for each service. Proxied for web apps, public for real-time protocols, internal for service-to-service communication. Elige el patrón de exposición correcto para cada servicio. Proxy para apps web, público para protocolos en tiempo real, interno para comunicación entre servicios.

🔀

PROXIEDPROXY

NGINX Path RoutingEnrutamiento por Ruta NGINX

Traffic flows through the project's NGINX reverse proxy. Multiple services share one domain with different URL paths. SSL termination, caching, and rate limiting handled at the proxy layer. El tráfico pasa por el proxy inverso NGINX del proyecto. Múltiples servicios comparten un dominio con diferentes rutas URL. Terminación SSL, caché y rate limiting gestionados en la capa de proxy.

Best for:Ideal para: REST APIs, web frontends, static sites APIs REST, frontends web, sitios estáticos

🌍

PUBLICPÚBLICO

Direct NodePortNodePort Directo

Bypasses NGINX for direct access on a dedicated port. The service handles its own SSL termination if needed. Essential for protocols that don't work behind a reverse proxy like WebSocket upgrades or gRPC streams. Salta NGINX para acceso directo en un puerto dedicado. El servicio gestiona su propia terminación SSL si es necesario. Esencial para protocolos que no funcionan detrás de un proxy inverso como WebSocket o streams gRPC.

Best for:Ideal para: WebSocket, gRPC, TCP/UDP, game servers WebSocket, gRPC, TCP/UDP, servidores de juegos

🔒

INTERNALINTERNO

ClusterIP

Only accessible within the Kubernetes cluster. Other services in the same project can reach it by service name. No external traffic allowed. Perfect for databases, caches, and internal microservices. Solo accesible dentro del clúster de Kubernetes. Otros servicios en el mismo proyecto pueden alcanzarlo por nombre. Sin tráfico externo permitido. Perfecto para bases de datos, cachés y microservicios internos.

Best for:Ideal para: Databases, Redis, internal APIs, workers Bases de datos, Redis, APIs internas, workers

🌐 ClientCliente

→

🛡️ HAProxy

→

☸ K8s NodePort

→

🔀 NGINX Proxy

→

🚀 ServicesServicios

🤖 AI-Native🤖 IA Nativa

Built for AI agents,
not just humans Hecho para agentes IA,
no solo humanos

80+ MCP tools give AI agents full control over your infrastructure. Deploy, scale, troubleshoot — all through natural conversation. 80+ herramientas MCP dan a los agentes IA control total sobre tu infraestructura. Despliega, escala, diagnostica — todo mediante conversación natural.

The MCP server exposes every API operation as a tool. AI agents can create projects, trigger builds, deploy services, read logs, manage SSL certificates, and orchestrate workflows — the same operations available through the REST API, but designed for LLM consumption. 100% API coverage means anything a human can do, an AI agent can do too. El servidor MCP expone cada operación de la API como una herramienta. Los agentes IA pueden crear proyectos, disparar builds, desplegar servicios, leer logs, gestionar certificados SSL y orquestar workflows — las mismas operaciones disponibles a través de la API REST, pero diseñadas para consumo de LLMs. Cobertura del 100% de la API significa que todo lo que un humano puede hacer, un agente IA también puede.

stdio transport HTTP/SSE transport API key → JWT Tiered rate limitingRate limiting por niveles

📦 ProjectsProyectos 8

🚀 ServicesServicios 12

🏗️ Builds 10

🔄 Workflows 9

🪝 Webhooks 6

🖼️ ImagesImágenes 8

🔐 VariablesVariables 5

🌐 CertificatesCertificados 4

💾 Snapshots 6

📋 TemplatesPlantillas 5

⏰ Scheduler 4

🔧 Composite 3+

                        
                        
                        
                        
                            ai-agent-deploy.js — AI agent deploying via MCP
                            ai-agent-deploy.js — Agente IA desplegando vía MCP
                        
                    

// AI agent conversation → infrastructure changes
// "Deploy my Node.js app with a PostgreSQL database"

// Step 1: Create a project
await mcp.call("create_project", {
  name: "my-node-app",
  domain: "my-node-app.hasslefree.tech"
});

// Step 2: Add PostgreSQL as an internal service
await mcp.call("create_service", {
  project: "my-node-app",
  name: "postgres",
  image: "postgres:16",
  exposure: "internal",
  env: { POSTGRES_PASSWORD: "<<DB_PASSWORD>>" },
  volumes: [{ mount: "/var/lib/postgresql/data", size: "10Gi" }]
});

// Step 3: Create build plan for the API
await mcp.call("create_build_plan", {
  project: "my-node-app",
  name: "api-plan",
  gitRepo: "https://github.com/user/my-node-app",
  dockerfile: "Dockerfile"
});

// Step 4: Build and deploy
await mcp.call("trigger_build", {
  project: "my-node-app",
  buildPlan: "api-plan"
});

// → Live at https://my-node-app.hasslefree.tech 🚀
                    

⑂ Git-Native⑂ Git Nativo

Your repo is the source of truth Tu repo es la fuente de verdad

Push, tag, open a PR, or type a slash command — HassleFree reacts to your Git workflow, not the other way around. Haz push, crea un tag, abre un PR, o escribe un comando slash — HassleFree reacciona a tu flujo Git, no al revés.

🐙 GitHub

🦊 GitLab

☕ Gitea

🪣 Bitbucket

Webhook EventsEventos de Webhook

Configure webhooks per branch pattern. HassleFree auto-registers endpoints on your Git provider and extracts commit SHA, branch, and repo URL into workflow variables. Build status is reported back as commit status checks with direct links to build logs. Configura webhooks por patrón de rama. HassleFree auto-registra endpoints en tu proveedor Git y extrae el SHA del commit, rama y URL del repo en variables del workflow. El estado del build se reporta como checks de estado de commit con enlaces directos a los logs.

push tag release pull_request pr_comment

Branch PatternsPatrones de Rama

Configure which branches trigger which workflows. Use glob patterns like main, release/*, or feat/** to route events to the right pipeline. Different branches can trigger different workflows — production deploy on main, ephemeral environment on feature branches. Configura qué ramas disparan qué workflows. Usa patrones glob como main, release/*, o feat/** para dirigir eventos al pipeline correcto. Diferentes ramas pueden disparar diferentes workflows — deploy a producción en main, entorno efímero en ramas feature.

PR Slash CommandsComandos Slash en PRs

Comment on a PR to trigger actions. Your team controls deployments from the same place they review code. HassleFree's bot picks up the comment, executes the action, and replies with the result. Comenta en un PR para disparar acciones. Tu equipo controla despliegues desde el mismo lugar donde revisa código. El bot de HassleFree detecta el comentario, ejecuta la acción y responde con el resultado.

/build Build the PR branchConstruir la rama del PR

/deploy Deploy to environmentDesplegar al entorno

/preview Spin up ephemeral envCrear entorno efímero

/status Current build statusEstado actual del build

Build Status ReportingReporte de Estado de Build

Every build reports its status back to the Git provider as a commit status check. Team members see ✅ or ❌ directly on the PR. Click through to see full build logs, image version, and deploy status. Merge with confidence. Cada build reporta su estado al proveedor Git como un check de estado de commit. Los miembros del equipo ven ✅ o ❌ directamente en el PR. Haz clic para ver logs completos del build, versión de imagen y estado del deploy. Mergea con confianza.

                        
                        
                        
                        
                            create-ephemeral.json
                            crear-efímero.json
                        
                    

// Clone full project with a feature branch
// Complete environment in ~2 minutes

POST /api/projects/my-app/ephemeral
{
  "branch": "feat/checkout-v2",
  "ttl": "7d",
  "cloneVolumes": true,
  "cloneVariables": true
}

// Response:
{
  "name": "my-app-feat-checkout-v2",
  "domain": "my-app-feat-checkout-v2.hasslefree.tech",
  "expiresAt": "2025-01-22T14:30:00Z",
  "services": 4,
  "status": "provisioning"
}

// ✓ All services, variables, build plans cloned
// ✓ Fresh DB credentials auto-generated
// ✓ Volume data restored from snapshots
// ✓ Build plans switched to feature branch
// ✓ Auto-cleanup in 7 days
                    

🧪 Preview Environments🧪 Entornos de Vista Previa

Spin up a full copy
in minutes Crea una copia completa
en minutos

Ephemeral projects clone everything — services, variables, build plans, volumes. Test feature branches in complete isolation. TTL from 1 hour to 30 days with auto-cleanup. Los proyectos efímeros clonan todo — servicios, variables, planes de build, volúmenes. Prueba ramas feature en aislamiento total. TTL de 1 hora a 30 días con limpieza automática.

🔀

Branch-Based CloningClonación por Rama

Point to any branch. All build plans switch to that branch automatically. Run builds and deploy the feature branch to its own isolated environment. Apunta a cualquier rama. Todos los planes de build cambian a esa rama automáticamente. Ejecuta builds y despliega la rama feature en su propio entorno aislado.

⏱️

TTL with Auto-CleanupTTL con Auto-Limpieza

Set 1 hour to 30 days. Extend if needed. All resources — K8s namespace, volumes, DNS entries, NGINX config — freed automatically on expiration. No zombie environments. Configura de 1 hora a 30 días. Extiende si es necesario. Todos los recursos — namespace K8s, volúmenes, entradas DNS, config NGINX — liberados automáticamente al expirar. Sin entornos zombie.

💾

Volume SnapshotsSnapshots de Volúmenes

Clone data from production via point-in-time snapshots. Realistic test environments with real data, not empty databases. Snapshots are read-only — zero risk to the original. Clona datos de producción vía snapshots puntuales. Entornos de prueba realistas con datos reales, no bases de datos vacías. Los snapshots son de solo lectura — cero riesgo para el original.

🔐

Isolated CredentialsCredenciales Aisladas

Fresh database passwords, API keys, and secrets generated per environment. Deploy-time variable <<random(32)>> ensures unique credentials. No cross-contamination between environments. Contraseñas de BD, API keys y secretos generados por entorno. La variable de deploy <<random(32)>> asegura credenciales únicas. Sin contaminación cruzada entre entornos.

🔒 Security & Auth🔒 Seguridad y Auth

Enterprise security,
zero configuration Seguridad empresarial,
cero configuración

Role-based access control, encrypted secrets, JWT authentication, and API key management — all built in. No external auth providers required. Control de acceso basado en roles, secretos encriptados, autenticación JWT y gestión de API keys — todo integrado. Sin proveedores de auth externos requeridos.

👥 RBAC — Five RolesRBAC — Cinco Roles

Fine-grained role-based access control with five built-in roles. Assign roles per project — an engineer might be Owner on their project but Read-only on another team's project. Control de acceso basado en roles con cinco roles incorporados. Asigna roles por proyecto — un ingeniero puede ser Owner en su proyecto pero Read-only en el de otro equipo.

Owner Admin Build Deploy Read

🔑 JWT + BitBot FederationJWT + Federación BitBot

JWT-based authentication with configurable token lifetimes. BitBot federation enables cross-service authentication — your CI/CD bot authenticates once and can operate across projects it has access to. Session management with token refresh. Autenticación basada en JWT con tiempos de vida configurables. La federación BitBot permite autenticación cross-service — tu bot CI/CD se autentica una vez y puede operar en todos los proyectos a los que tiene acceso. Gestión de sesiones con token refresh.

🔐 AES-256 Encrypted SecretsSecretos Encriptados AES-256

All project variables marked as secrets are encrypted with AES-256 at rest. Secrets are only decrypted at deploy-time via <<VAR>> substitution — they never appear in build logs, API responses, or version control. Rotatable encryption keys. Todas las variables de proyecto marcadas como secretos se encriptan con AES-256 en reposo. Los secretos solo se desencriptan en tiempo de despliegue vía sustitución <<VAR>> — nunca aparecen en logs de build, respuestas API o control de versiones. Claves de encriptación rotables.

🗝️ API Key AuthenticationAutenticación por API Key

Generate API keys with specific role bindings for automation. The MCP server uses API keys that are exchanged for JWTs on first use. Keys can be scoped to specific projects and have configurable expiration. Revoke instantly. Genera API keys con roles específicos para automatización. El servidor MCP usa API keys que se intercambian por JWTs en el primer uso. Las keys pueden limitarse a proyectos específicos con expiración configurable. Revocación instantánea.

📂 Project-Scoped CredentialsCredenciales por Proyecto

Git tokens and secrets are stored per-project, not per-user. Different projects can access different repositories. Improves security isolation and simplifies team management — rotate one project's tokens without affecting others. Los tokens Git y secretos se almacenan por proyecto, no por usuario. Diferentes proyectos pueden acceder a diferentes repositorios. Mejora el aislamiento de seguridad y simplifica la gestión — rota los tokens de un proyecto sin afectar otros.

🏗️ Namespace IsolationAislamiento de Namespaces

Each project gets its own Kubernetes namespace with resource quotas, network policies, and service accounts. Workloads are fully isolated — one project cannot access another's pods, volumes, or secrets. Defense in depth at the orchestration layer. Cada proyecto obtiene su propio namespace de Kubernetes con cuotas de recursos, políticas de red y service accounts. Las cargas de trabajo están completamente aisladas — un proyecto no puede acceder a los pods, volúmenes o secretos de otro.

CapabilityCapacidad	Owner	Admin	Build	Deploy	Read
View project & resourcesVer proyecto y recursos	✓	✓	✓	✓	✓
Deploy & restart servicesDesplegar y reiniciar servicios	✓	✓	–	✓	–
Trigger & manage buildsDisparar y gestionar builds	✓	✓	✓	–	–
Manage services & workflowsGestionar servicios y workflows	✓	✓	–	–	–
Manage variables & secretsGestionar variables y secretos	✓	✓	–	–	–
Manage team membersGestionar miembros del equipo	✓	–	–	–	–
Delete projectEliminar proyecto	✓	–	–	–	–

⚙️ Architecture⚙️ Arquitectura

Production-grade,
three-tier architecture Arquitectura de tres capas,
calidad producción

Traffic flows through three layers of routing — from the firewall to your services. Each layer handles a specific concern: external load balancing, Kubernetes networking, and per-project reverse proxy. El tráfico fluye a través de tres capas de enrutamiento — desde el firewall hasta tus servicios. Cada capa maneja una responsabilidad específica: balanceo de carga externo, networking de Kubernetes y proxy inverso por proyecto.

🛡️ Layer 1 — Edge🛡️ Capa 1 — Edge

OpnSense firewall with HAProxy for external load balancing. Handles TLS termination for the platform itself, DDoS protection, and routes traffic to Kubernetes NodePorts. Firewall OpnSense con HAProxy para balanceo de carga externo. Gestiona terminación TLS para la plataforma, protección DDoS y enruta tráfico a NodePorts de Kubernetes.

OpnSense HAProxy

☸️ Layer 2 — Kubernetes☸️ Capa 2 — Kubernetes

Kubernetes NodePort services receive traffic and route to project namespaces. Each project gets its own namespace with resource quotas, network policies, and service accounts. Full namespace isolation. Los servicios NodePort de Kubernetes reciben tráfico y lo enrutan a namespaces de proyecto. Cada proyecto obtiene su propio namespace con cuotas de recursos, políticas de red y service accounts. Aislamiento total de namespace.

NodePort Namespaces

🔀 Layer 3 — Project🔀 Capa 3 — Proyecto

Per-project NGINX reverse proxy handles path-based routing, SSL termination for custom domains, WebSocket upgrades, caching headers, and request buffering. Auto-configured when services are deployed. El proxy inverso NGINX por proyecto gestiona enrutamiento por ruta, terminación SSL para dominios personalizados, upgrades WebSocket, headers de caché y buffering de requests. Auto-configurado al desplegar servicios.

NGINX Path routingRutas

🌐 InternetInternet

→

🛡️ OpnSense
HAProxy

→

☸️ K8s
NodePort

→

🔀 NGINX
Per-projectPor proyecto

→

🚀 Your ServicesTus Servicios

Deploy to Kuberneteswithout the YAML Despliega en Kubernetessin escribir YAML

Six building blocks,infinite possibilities Seis piezas fundamentales,posibilidades infinitas

ProjectsProyectos

ImagesImágenes

Build PlansPlanes de Build

ServicesServicios

WorkflowsWorkflows

Webhooks

Everything you need to ship,nothing you don't Todo lo que necesitas para desplegar,nada que no

Container BuildsBuilds de Contenedores

One-Click DeployDespliegue en un Clic

CI/CD WorkflowsWorkflows CI/CD

Auto SSLSSL Automático

Smart RoutingEnrutamiento Inteligente

Project TemplatesPlantillas de Proyecto

Auto-VersioningAuto-Versionado

Variable SubstitutionSustitución de Variables

Sidecar ContainersContenedores Sidecar

Volume SnapshotsSnapshots de Volúmenes

SchedulerProgramador

Plugin SystemSistema de Plugins

Role-Based AccessControl de Acceso por Roles

Real-time EventsEventos en Tiempo Real

From git pushto production Desde git pushhasta producción

Git Push → WebhookGit Push → Webhook

Build Container ImageConstruir Imagen

Deploy to KubernetesDesplegar en Kubernetes

Live on Your DomainEn Vivo en tu Dominio

From source codeto container image Del código fuentea imagen de contenedor

Git Source PriorityPrioridad de Fuente Git

Multi-Stage DockerfilesDockerfiles Multi-Etapa

Auto-VersioningAuto-Versionado

Sequential Build QueueCola de Build Secuencial

Git Status ReportingReporte de Estado Git

CloneClonar

InjectInyectar

BuildConstruir

PushSubir

ReportReportar

Five syntaxes, five contexts,one powerful system Cinco sintaxis, cinco contextos,un sistema poderoso

Three ways to exposeyour services Tres formas de exponertus servicios

NGINX Path RoutingEnrutamiento por Ruta NGINX

Direct NodePortNodePort Directo

ClusterIP

Built for AI agents,not just humans Hecho para agentes IA,no solo humanos

Your repo is the source of truth Tu repo es la fuente de verdad

Webhook EventsEventos de Webhook

Branch PatternsPatrones de Rama

PR Slash CommandsComandos Slash en PRs

Build Status ReportingReporte de Estado de Build

Spin up a full copyin minutes Crea una copia completaen minutos

Branch-Based CloningClonación por Rama

TTL with Auto-CleanupTTL con Auto-Limpieza

Volume SnapshotsSnapshots de Volúmenes

Isolated CredentialsCredenciales Aisladas

Enterprise security,zero configuration Seguridad empresarial,cero configuración

👥 RBAC — Five RolesRBAC — Cinco Roles

🔑 JWT + BitBot FederationJWT + Federación BitBot

🔐 AES-256 Encrypted SecretsSecretos Encriptados AES-256

🗝️ API Key AuthenticationAutenticación por API Key

📂 Project-Scoped CredentialsCredenciales por Proyecto

🏗️ Namespace IsolationAislamiento de Namespaces

Production-grade,three-tier architecture Arquitectura de tres capas,calidad producción

🛡️ Layer 1 — Edge🛡️ Capa 1 — Edge

☸️ Layer 2 — Kubernetes☸️ Capa 2 — Kubernetes

🔀 Layer 3 — Project🔀 Capa 3 — Proyecto

Production-grade stackStack de producción

Ready to deploywithout the hassle? ¿Listo para desplegarsin complicaciones?

Deploy to Kubernetes
without the YAML Despliega en Kubernetes
sin escribir YAML

Six building blocks,
infinite possibilities Seis piezas fundamentales,
posibilidades infinitas

Everything you need to ship,
nothing you don't Todo lo que necesitas para desplegar,
nada que no

From git push
to production Desde git push
hasta producción

From source code
to container image Del código fuente
a imagen de contenedor

Five syntaxes, five contexts,
one powerful system Cinco sintaxis, cinco contextos,
un sistema poderoso

Three ways to expose
your services Tres formas de exponer
tus servicios

Built for AI agents,
not just humans Hecho para agentes IA,
no solo humanos

Spin up a full copy
in minutes Crea una copia completa
en minutos

Enterprise security,
zero configuration Seguridad empresarial,
cero configuración

Production-grade,
three-tier architecture Arquitectura de tres capas,
calidad producción

Ready to deploy
without the hassle? ¿Listo para desplegar
sin complicaciones?