---
id: "service-shell"
type: "concept"
title: "The service shell"
summary: "Servix is the lifecycle shell around your logic — it supervises, schedules, logs, and persists, but never becomes the business logic."
problem: "Without a shell, every background job reinvents process supervision, logging, health checks, and state persistence."
why: "Keeping business logic and runtime concerns separate means the wrapped code stays testable and reusable outside Servix."
mentalModel: "Your existing code = business logic. Servix = lifecycle + background runtime + scheduler + logs + health + state."
audiences: ["developers"]
related: ["wrap-once-run-managed", "listener-vs-proactive"]
next: ["wrap-a-function"]
---
# The service shell

Servix should not be "the thing doing the business logic". The flow is always:

```txt
existing function / CLI / package
        ↓
Servix wrapper (defineServixService)
        ↓
managed background service
        ↓
start / pause / stop / status / logs
```

The wrapper is usually tiny — one `defineServixService` call that delegates to your existing function, command, or handler.