Deploying and running functions

#Ways to deploy

The entry file is main.py (Python) or index.mjs / index.js (Node.js); --entrypoint and --handler change it. Every deploy is a new version; a deploy that fails never replaces the version serving traffic.

sov fn deploy ./functions/send-receipt --name send-receipt --note "retry on 5xx"
sov fn versions send-receipt
sov fn rollback send-receipt          # back to the previous version

#Dependencies

The standard library (Python) and built-ins such as fetch (Node.js) are always there. To ship packages, vendor them with your code and deploy with --include-deps (bundles node_modules or vendored Python packages) — available on paid plans.

#Environments

Deploying through an environment's URL (staging, a version) creates that environment's own copy; production keeps serving its version. When the change is ready, promote it to production — Environments, staging and deploying to production. Secrets and environment variables stay per environment, so staging never uses production keys.

#Call it

Successful responses carry X-Sovaria-Invocation-Id (find the run in the logs), X-Sovaria-Duration-Ms and X-Sovaria-Compute-GB-Seconds.

#Errors

HTTP calls are not retried for you. Event triggers retry failed runs and keep the ones that keep failing in a dead-letter queue, so write handlers that can safely run twice (check whether the work was already done before doing it).

#Start-up and concurrency

• Functions run in isolated sandboxes that are reused between calls when possible; the first call after a deploy or a quiet period can take longer.
• Create clients and read configuration at module level, not inside the handler, so warm calls skip it.
• How many runs may execute at once is set by your plan; beyond it a call waits briefly, then gets 429 PLAN_LIMIT_REACHED (fn.concurrency) with Retry-After: 2.

#Read and write your data from a function

Store a server key as a secret and call your project's API with it. Because a server key passes every access policy, decide in your code what the caller may do — use context.caller — before acting for them.

const URL = process.env.SOVARIA_URL               // https://<project-ref>.sovarias.in
const KEY = process.env.SOVARIA_SERVICE_ROLE_KEY       // bound as a secret

export async function handler(event, context) {
  const userId = context.caller.user_id
  if (!userId) return { error: 'sign in first' }

  const res = await fetch(`${URL}/api/v1/sql/query`, {
    method: 'POST',
    headers: { apikey: KEY, 'Content-Type': 'application/json' },
    body: JSON.stringify({ sql: 'select id, total from orders where customer_id = $1', params: [userId] }),
  })
  return await res.json()
}

• Add your project host to the function's allowed hosts — functions can only reach hosts you list.
• Pass values as params, never inside the SQL string.
• Prefer a custom key with only the access the function needs over the service role key (Keys, tokens and credentials).