Socaity CLI Reference
pip install socaity registers a socaity command on your shell. It is the unified CLI for authentication, installing catalog services, and deploying your own. Auth and service management run directly. The deploy commands wrap APIPod.
socaity CLI is what you run day to day (login, install services, deploy). Its scan / build / start commands delegate to APIPod, the underlying packaging-and-deploy engine documented in full on its own page. Installing the SDK puts the socaity executable on your PATH (entry point socaity = socaity.cli:main). A fresh install ships no model stubs. You add a service with socaity install <service> (and pull the official ones with socaity update). The service registry then keeps your installed set in sync at import time.
pip install socaity| Command | What it does | Auth |
|---|---|---|
socaity login | Authenticate via browser and store credentials on disk. | public |
socaity logout | Remove stored credentials. | public |
socaity whoami | Show the logged-in user. | login required |
socaity install <id> | Install a catalog service by id (also -i <id>). | login required |
socaity update | Sync installed services with the platform. | login required |
socaity scan | Generate apipod.json for your project (via APIPod). | login required |
socaity build [file] | Build the deployment container (via APIPod). | login required |
socaity start | Run your service locally or on a provider (via APIPod). | login required |
install, update, scan, build, and start read stored credentials from socaity login (saved under ~/.config/socaity/credentials.json). If you are not logged in they print Not logged in. Run: socaity login and exit. These commands have no env-var fallback. When you call models from Python, the SDK uses your stored login key, or falls back to SOCAITY_API_KEY if it is set. socaity login opens a browser, completes sign-in at socaity.ai, and stores a scoped key on disk, much like gh auth login. Use --no-browser on headless machines.
# Authenticate once: opens a browser and stores a scoped key on disk.
socaity login
# Headless / CI machines:
socaity login --no-browser
# Inspect or end your session.
socaity whoami
socaity logoutPin a catalog service to generate its Python client, then keep your installed set in sync. Install only the services you need, one catalog id at a time. Find ids on the API catalog.
# Install a catalog service so its typed client becomes importable.
socaity install black-forest-labs/flux-schnell
# Short flag form for another service.
socaity -i deepseek-ai/deepseek-v3
# Sync already-installed services with the platform.
socaity updatescan, build, and start package and run a service you wrote. They delegate to APIPod; see its reference for the full flag set, providers, and compute types.
# Package and run a service you built (these delegate to APIPod).
socaity scan # generate apipod.json
socaity build main.py --provider runpod # build the deploy container
socaity start --compute serverless --provider runpodsocaity -h # list all commands and flags
socaity login --help # per-command help After socaity install, import the service and call it. Authentication comes from your socaity login session, or from SOCAITY_API_KEY if you set it explicitly.
import os
from socaity.sdk.replicate.black_forest_labs import flux_schnell
# After `socaity login`, the stored key is used automatically.
# On CI / servers, set the env var yourself instead:
flux = flux_schnell(api_key=os.getenv("SOCAITY_API_KEY"))
image = flux(prompt="a cat on mars").get_result()
image.save("cat.png")- Deploy commands reference : the deploy engine behind
socaity scan / build / start. Full flags, providers, and compute types. - Python SDK reference : how to import services, submit jobs, and read results.
- Secrets : generate a
SOCAITY_API_KEYfor CI or servers where browser login is not available. - Server updates : how the service registry keeps model stubs in sync.