Overview

The Rebase Platform is used through the rebase-toolkit SDK. Install the toolkit, run rebase setup once to authenticate this computer, then define and deploy functions, Rebase Workflows, and models from Python.

pip install rebase-toolkit
rebase setup

import rebase as rb

project = rb.project("energy-forecasting")

The SDK talks to the hosted Rebase API using a built-in platform URL. Users should not set an API URL for normal usage; the local setup command stores an auth session and selected workspace profile on the computer.

The platform has seven core surfaces:

Area	Purpose
System	Check API and database health.
Workspace	Configure members, invites, and Rebase-hosted or GitHub-backed source backing for your team.
Projects	Create namespaces inside a workspace.
Functions	Register SDK-callable Python functions. Functions use the `quick` run type by default and can use `quick_shared` or `long` when needed.
Workflows	Register pipeline-style workflow definitions and inspect immutable versions.
Models	Version, deploy, promote, run, and publish prediction-oriented model targets.
Endpoints	Expose deployed functions, workflows, and models over stable HTTP routes.
Runs	Trigger function, workflow, or model execution pinned to an exact version.

Authentication

Run setup once:

rebase setup

The command signs you in with Google or GitHub, creates or selects a workspace, and stores a local profile for the selected workspace. Project, function, workflow, model, and run queries are scoped to the active workspace, so callers only see records they can access.

Workspace owners can invite collaborators by email address or GitHub handle:

rebase workspace invite davide@rebase.energy --role Developer
rebase workspace members

Object Model

Workspace
  Project
    Function
      FunctionVersion
    Workflow
      WorkflowVersion
    Model
      ModelVersion
      ModelDeployment
      ModelPublication
    Endpoint
      EndpointVersion
    Run

Projects are the namespace boundary. Function, workflow, model, and endpoint names are unique inside a project, and SDK callers can reference shared targets with project/name.

Source backing is optional. New workspaces default to rebase_hosted, where the SDK stores executable source snapshots directly in Rebase. A workspace can also point to one GitHub repo, with each project using a folder, or individual projects can point to their own repos.

Execution Model

Functions, workflows, and models are executable targets:

Target	Use it when
Function	You want a low-latency SDK-callable Python function. Functions default to `run_type="quick"` (isolated Cloud Run) and also accept `quick_shared` and `long`.
Workflow	You want a pipeline or Prefect-style orchestration target. Workflows default to `run_type="quick"` (warm Cloud Run service) and accept `long` for Cloud Run Jobs execution.
Model	You want a versioned prediction, optimization, or agent target with environment promotion, rollback, and model lineage.

Function, workflow, and model names are stable handles. Deploys create or reuse immutable versions behind those handles:

Field	Meaning
`source_code` plus `entrypoint`	Python source captured by the SDK.
`flow_ref`	Backwards-compatible workflow reference already packaged in the runner image.
`fingerprint`	Hash of executable source, defaults, enabled state, dependency image spec, and provenance metadata.
Git metadata	Optional repo/path/commit fields for GitHub-backed or local Git deploys.

Runs store target_version_id, so they execute the exact function, workflow, or model version selected at submission time. Functions, models, and workflows default to run_type="quick"; functions and models run that synchronously on isolated Cloud Run, while workflows use the warm Cloud Run service path backed by Prefect. Use run_type="long" for long-running Cloud Run Jobs execution. See Run Types for the full comparison and latency shape.

Endpoints are optional HTTP routes for deployed targets. They create normal Rebase runs and store endpoint metadata on those runs. See Endpoints for route shape, auth modes, and CLI invocation.

Hugging Face

Model versions can be published to Hugging Face model or dataset repositories. Publications are anchored to the immutable Rebase model version and the Hub commit returned by upload. GitHub/Git sync is optional, so teams can publish private or public Hub repos even when a model is not backed by a GitHub repository.

See Hugging Face for setup, artifact publishing, dataset repos, and optional Git sync.

Reference

Use the SDK pages for normal integration. The API reference pages in this site are generated from openapi.yaml and rendered by Fumadocs OpenAPI for advanced tooling and platform debugging.