A container lifecycle is the sequence of events a container goes through — created, started, stopped, deleted. Automating around those events means your other systems (billing, monitoring, chat, dashboards) find out the moment something happens, without anyone polling or checking manually. The two tools for this are webhooks (the panel tells you when something happens) and a REST API (you tell the panel to make something happen). Together they turn container management from a series of manual clicks into a programmable system. This post shows how the pieces fit.
Push versus pull: why webhooks matter
Without webhooks, keeping an external system aware of your containers means polling — asking "anything changed?" on a timer, most of which returns "no". Polling is wasteful, laggy, and scales badly. Webhooks invert it: the panel pushes a notification to a URL you specify the instant an event occurs. Your system does nothing until there is something to react to, and then it reacts immediately.
Panelica emits events across the platform, and for containers specifically it fires on the four lifecycle moments:
| Event | Fires when | Typical reaction |
|---|---|---|
docker.container_created | A new container is deployed | Record it, start billing, notify the team |
docker.container_started | A container starts running | Begin monitoring, mark service available |
docker.container_stopped | A container stops | Alert if unexpected, pause metering |
docker.container_deleted | A container is removed | Stop billing, clean up related records |
Where the events can go
A webhook does not have to hit a custom application. Panelica can deliver events to several destinations, so the simplest useful automation needs no code at all:
- An HTTP endpoint — your own service receives a JSON payload and does whatever your business logic requires. This is the powerful, build-anything option.
- Chat notifications — deliver events straight to Telegram, Slack, or Discord, so "a container just stopped" appears in your team channel without any glue code.
The chat integrations are the fastest win: point container-stopped and container-deleted events at a Slack or Telegram channel and you have live operational awareness in ten minutes. Our general webhook notifications guide walks through setting these up.
The API: making things happen programmatically
Webhooks tell you about events. The REST API lets you cause them. Every container operation you can do in the panel — deploy from a template, start, stop, restart, remove, inspect, read logs — is available as an API call. That is what makes container management programmable: a script, a billing system, or a scheduled job can deploy and control containers with no human clicking.
Panelica actually exposes this at two levels, and the distinction matters for automation:
- The internal REST API — the same API the panel's own interface uses, authenticated with API keys, for tools operating on behalf of a logged-in account.
- The External API — a separate, hardened interface authenticated with HMAC-SHA256 request signing, built for server-to-server automation where a billing platform or orchestrator drives the panel. Request signing means each call carries a cryptographic signature proving it came from a holder of the shared secret and was not tampered with in transit — the right security model for machine-to-machine calls.
Putting them together: a worked example
Consider a metered container-hosting service. The full loop uses both tools:
- A customer's paid order triggers your billing system to call the External API (HMAC-signed) to deploy their app from a template into their isolated account.
- The deployment fires
docker.container_created, which hits your webhook endpoint — you record the container against the customer and start the billing clock. docker.container_startedtells your monitoring to begin watching the service.- If the container later stops unexpectedly,
docker.container_stoppedlands in your team's Slack, and your system can decide whether to alert the customer. - When the customer cancels, your billing calls the API to remove the container;
docker.container_deletedcloses out the billing record.
No human touched a container in that entire flow. That is the point — and it is the automation backbone behind selling one-click apps as a business.
Practical advice for building on this
- Make webhook handlers idempotent. Networks retry; the same event may arrive twice. Design your handler so processing an event twice is harmless.
- Verify the source. For HTTP webhook endpoints, confirm the request genuinely came from your panel (a shared secret or signature check) before acting on it — a webhook URL that anyone can trigger is a liability.
- Use the External API for server-to-server, not the user API. The HMAC-signed External API is designed for exactly the billing-and-orchestration case; do not thread user API keys through backend systems.
- Respond fast, work async. Acknowledge a webhook quickly and do heavy processing in the background, so a slow job does not cause delivery retries.
Frequently asked questions
Do I need to write code to use webhooks?
Not for the chat destinations — pointing events at Telegram, Slack, or Discord is configuration, not code. You need code only when you build custom logic behind an HTTP endpoint.
What is the difference between the internal and external API?
The internal API serves tools acting as a logged-in user, with API-key auth. The External API is for server-to-server automation, secured with HMAC-SHA256 request signing — the appropriate model when a billing system or orchestrator drives the panel without a human session.
What happens if my webhook endpoint is down when an event fires?
Delivery mechanisms generally retry, but you should not treat webhooks as guaranteed-once delivery. For anything critical, reconcile periodically by querying the API for actual state, so a missed webhook self-corrects.
Can I automate non-container operations the same way?
Yes. Containers are one event domain among many — Panelica emits events and exposes API operations across the platform, so the same push-and-pull pattern applies to domains, accounts, backups, and more.
The takeaway
Webhooks and a REST API are the two halves of programmable infrastructure: events push out the moment a container is created, started, stopped, or deleted; the API lets your systems deploy and control containers without a human. Panelica provides both — four container lifecycle events deliverable to HTTP, Telegram, Slack, or Discord, and an API available at both a user level and a hardened HMAC-signed External level for server-to-server work. Wire them together and container operations become a system you build on, not a screen you babysit.