Le service aura-functions stocke vos fonctions et les exécute de trois manières : invocation HTTP synchrone (POST /v1/functions/:projectId/:nom/invoke), job asynchrone (mis en file, exécuté par un pool de workers), et cron (qui crée un job à chaque échéance). Il n'y a pas trois types de fonctions : c'est la même fonction, déclenchée différemment.
Contrat d’entrée
Une fonction Deno déclare son point d'entrée avec Deno.serve(handler). Un export default n'est jamais appelé : la fonction n'ouvre alors aucun listener et l'invocation est abandonnée à l'échéance de son timeout_secs.
Info
Chaque invocation Deno s'exécute dans un isolat V8 dédié, avec sa propre heap, sa limite mémoire et son timeout wall-clock. Un plantage dans une fonction n'affecte pas les autres.
Le code source (Deno) ou le binaire encodé (WASM) est stocké dans la base du projet. À la première invocation, le runtime edge récupère le code et les permissions, écrit la source sur son volume, crée un worker isolé, puis lui transmet la requête. Le code est mis en cache côté runtime et le cache est invalidé à chaque déploiement.
cycle de vie d’une invocation
TEXT
DEPLOY ────▶ code stocké en base + cache du runtime invalidé
ISOLATE ────▶ worker V8 créé (memory_mb, timeout_secs)
EXEC ────▶ la requête demandée est passée au handler
KILL ────▶ worker terminé à l’échéance de timeout_secs
Pas de réseau de points de présence
Aurabase n'a pas de distribution multi-régions : les fonctions s'exécutent sur le runtime edge de votre déploiement. Il n'y a ni sélection de région, ni propagation mondiale, ni déploiement éphémère par branche.
Il n'y a pas d'objet ctx injecté dans votre fonction : vous écrivez du Deno standard. Pour joindre la base, le stockage ou l'IA depuis une fonction, utilisez le SDK ou l'API HTTP d'Aurabase, avec une clé fournie en secret — et pensez à autoriser le domaine dans allow_net.
Chiffrés en base, injectés comme variables d’environnement
Les secrets sont définis par fonction. Le serveur les chiffre en AES-256-GCM, avec une clé dérivée par enregistrement, et le runtime edge les injecte dans le worker : votre code les lit avec Deno.env.get('CLE').
cli
BASH
# Définir des secrets (paires KEY=VALUE)
aura secrets set --function echo STRIPE_SECRET_KEY=sk_live_...
# Lister les secrets d’une fonction (valeurs masquées)
Le chiffrement des secrets dépend de la variable serveur FN_ENV_ENCRYPTION_KEY. Si elle n'est pas définie, aura-functions le signale au démarrage et stocke les valeurs en clair — acceptable en développement local, à proscrire en production.
Chaque fonction porte ses propres permissions, modifiables depuis le Studio ou par PATCH /v1/functions/:projectId/:nom. Une valeur hors bornes est refusée, jamais rabotée en silence.
permissions
JSON
{
"memory_mb": 128, // 16 à 1024, défaut 128
"timeout_secs": 30, // 1 à 300, défaut 30 — wall-clock
"allow_net": ["api.stripe.com"]
}
allow_net n’est pas encore appliqué par le runtime
La version du runtime edge utilisée n'expose pas d'allowlist réseau par worker : allow_net est stocké et affiché, mais l'isolation réseau réelle est assurée au niveau plateforme (le runtime est sur un réseau séparé de l'infrastructure). Ne comptez pas dessus comme barrière d'egress.
Dépassement du budget
À l'échéance de timeout_secs, le runtime termine le worker et l'appel remonte une erreur d'exécution. Un job dont l'invocation échoue est retenté puis, les tentatives épuisées, versé en DLQ.
