Skip to Content
Server FunctionsBuild & Deploy Functions

Server Functions (CLI)

Declare server functions in SQL with CREATE FUNCTION or CREATE PROCEDURE, implement them as project TypeScript (or inline JavaScript), then let the CLI generate, build, and activate the module.

The SQL contract, CALL, HTTP /v1/functions, topic triggers, and schedules are documented in Server Functions. This page is the CLI lifecycle.

Schema-first loop

  1. Add a bodyless CREATE FUNCTION or CREATE PROCEDURE (and any CREATE TYPE it needs) to your schema file.
  2. Run kalam schema gen (or let kalam dev do it).
  3. Implement functions/src/<schema>/<procedure>.ts.
  4. Activate with kalam dev or kalam deploy.
SQL
CREATE TYPE chat.message_target AS ENUM ('room', 'direct'); CREATE FUNCTION chat.send_message(  target chat.message_target NOT NULL,  target_id TEXT NOT NULL,  content TEXT NOT NULL)RETURNS chat.ai_inboxSECURITY INVOKER; GRANT EXECUTE ON FUNCTION chat.send_message TO user;
BASH
kalam schema gen# edit functions/src/chat/send_message.tskalam deploy --env dev

kalam schema gen writes procedure.<schema>.<method>(handler) builders and a one-time named-export scaffold for each unbound procedure. Existing implementations are preserved. Do not hand-edit functions/src/generated/.

.unimplemented() scaffolds typecheck and build but are omitted from the compiled registry. CALL fails with procedure not implemented until a real handler is activated.

kalam dev

After the schema pipeline, kalam dev builds functions/ and activates the project module (same activation as kalam deploy). Failures print as errors; they do not stop the app process. Watched edits to functions/src rebuild and reactivate.

Use matching CLI and server versions. Function deployment includes SQL and JavaScript activation; check both when a call fails.

See Local Development.

kalam deploy

kalam deploy generates schema artifacts, builds the project’s server functions, applies migrations, activates the function module, and checks target health.

BASH
kalam deploy --env dev --dry-run  # generate + build only; no migrate/activatekalam deploy --env devkalam deploy --env prod

Deployment does not publish or start frontend, mobile, or service applications; use your application rollout process. See the complete schema evolution lifecycle.

The dry run does not apply migrations, upload functions, or activate a revision. Production-like environments still require sealed migrations when automatic migrations are enabled.

kalam functions

Build and inspect independently of a full deploy:

BASH
kalam functions buildkalam functions status --env devkalam functions revisions --env devkalam functions runtime --env devkalam functions logs --env devkalam functions logs chat.send_message --env devkalam functions override chat.send_messagekalam functions rollback backend:<artifact> --env dev
CommandPurpose
buildCompile functions/ without activating
statusCurrent module, every procedure (implementation + signature), isolate stats
revisionsModule history with is_current
runtimeResident V8 isolates and in-flight root calls
logsRecent invocation, console / ctx.log, and error records from system.procedure_logs
overrideOperator override for a procedure
rollbackActivate a previous revision without rebuilding

Rollback identifiers come from kalam functions revisions. Rollback does not undo schema migrations.

On disk, invocation logs live under {data_path}/functions/runtime/<procedure_id>/logs/ (default ./data/functions/runtime/...). Compiled module bytes live under {data_path}/functions/artifacts/.

Create & Call ProceduresTyped SDK Routine Calls