~/sursakit

// docs

Service

A service is one containerized component of a workspace. Most projects compose several: a frontend, an API, a database, sometimes a worker or a queue.

Service sources

When you add a service to a workspace, you pick how it's sourced:

  • GitHub import — OAuth-connect a repo; Sursakit clones into the service.
  • GitLab import — same flow against GitLab.
  • Bitbucket import — same flow against Bitbucket.
  • Docker Hub — pull a public or authenticated image.
  • Upload — push a zip or folder from your machine.
  • Empty — scaffold from scratch.
  • Database — pick a managed database template.

What a service holds

  • Type — application, database, image, etc.
  • Base image — the container image the runtime is built from.
  • Environment variables — declared per service, encrypted at rest.
  • Volume mounts — for state that needs to persist across runtime restarts.
  • Runtime limits — CPU and memory caps applied to the service's container.
  • Order — services in a workspace are ordered for display and run-all sequencing.

Lifecycle

Each service's runtime is a container scoped to a session. Operate on it through:

  • Run / Stop / Restart — per-service.
  • Run all / Stop all — workspace-wide.
  • Logs — streamed back to the workbench.
  • Terminal — a real PTY attached to the running container.

API surface

Under /api/v1/workspace/{session_id}/services and /api/v1/workspace/{session_id}/runtimes:

  • POST /services — create a service.
  • POST /services/import-github | import-gitlab | import-bitbucket | import-dockerhub — typed import flows.
  • GET /services, PUT /services/{id}, DELETE /services/{id} — list, update, delete.
  • PUT /services/reorder — reorder.
  • POST /runtimes/{service_id}/restart | stop — runtime control per service.
  • POST /runtimes/run-all | stop-all — bulk runtime control.

Database services additionally expose config, schema, table data, and SQL query endpoints under /services/{service_id}/database.

Reuse

A service belongs to its workspace's session, but the underlying source (a Git repo or Docker image) is yours — there's no lock-in. Connect the same repo to multiple workspaces if you want parallel experiments.