Browser Service is an HTTP API and event streaming layer for the Selenosis ecosystem.
It provides a REST interface and real-time events on top of the Browser resources managed by browser-controller.
This service does not create Pods directly. Instead, it operates as a client-facing facade over Kubernetes Browser CRDs.
- Browser Service exposes CRUD and event APIs for browser instances.
- browser-controller is responsible for reconciliation and Pod lifecycle.
- Browser CRD is the shared contract between the service and the controller.
The service watches Browser resources and streams lifecycle events to clients.
- Expose HTTP API for managing
Browserresources - Stream browser lifecycle events (ADDED / MODIFIED / DELETED)
- Provide read-only access to
Browser.status - Act as a thin abstraction over Kubernetes APIs
Browser Service depends on browser-controller for:
BrowserCRD definitions- Generated clientsets, informers, and listers
- Actual browser Pod creation and lifecycle management
The service assumes that:
- CRDs are already installed
- browser-controller is running in the cluster
All APIs are namespaced.
-
POST /api/v1/namespaces/{namespace}/browsers
Create a newBrowser -
GET /api/v1/namespaces/{namespace}/browsers/{name}
Get a singleBrowser -
DELETE /api/v1/namespaces/{namespace}/browsers/{name}
Delete aBrowser -
GET /api/v1/namespaces/{namespace}/browsers
List all Browsers in a namespace -
GET /api/v1/namespaces/{namespace}/events
Stream browser events (server-sent events over HTTP)Query parameters (optional):
name— filter events by browser name.
When specified, only events related to the given browser are streamed.
The service exposes a streaming endpoint backed by shared informers.
Event types:
ADDEDMODIFIEDDELETED
Each event contains the full Browser object as payload.
- The service uses shared informers to watch
Browserresources. - Events are broadcast to connected clients using an in-memory fan-out broadcaster.
- No state is persisted outside of Kubernetes.
- All writes are forwarded directly to the Kubernetes API server.
GET /healthzReturns 200 OK when the service is running.
The project is built and packaged entirely via Docker. Local Go installation is not required for producing the final artifact.
The build process is controlled via the following Makefile variables:
Variable Description
- BINARY_NAME Name of the produced binary (selenosis).
- REGISTRY Docker registry prefix (default: localhost:5000).
- IMAGE_NAME Full image name (/selenosis).
- VERSION Image version/tag (default: develop).
- PLATFORM Target platform (default: linux/amd64).
- CONTAINER_TOOL docker cmd
REGISTRY, VERSION is expected to be provided externally, which allows the same Makefile to be used locally and in CI.
Helm chart selenosis-deploy