Chaque service a son propre onglet Variables, indépendant de tous les autres services du projet — rien n'est partagé sauf si vous le copiez vous-même. « New Variable » ajoute une ligne KEY = value toute simple ; la saisie continue jusqu'à ce que vous cliquiez sur Done.
Secrets
Marquer une variable Secret lors de sa création masque sa valeur partout dans l'interface par défaut (une icône œil la révèle à la demande) — pensé pour les clés API, mots de passe de base de données, et tout ce qui ne devrait pas être visible lors d'un partage d'écran. Une variable existante peut être transformée en secret plus tard depuis le menu de sa ligne, sans avoir à la supprimer et la recréer.
Variables au build vs. au runtime
La plupart des variables sont lues au runtime, donc mettre à jour une valeur et redéployer suffit — pas besoin de rebuild. Les frameworks qui intègrent les variables d'environnement directement dans le bundle compilé au moment du build (les variables préfixées VITE_ de Vite sont le cas courant) font exception : Qeda suit cette distinction par clé en interne, et l'invite de déploiement vous dit clairement si ce que vous avez changé nécessite un rebuild ou juste un redéploiement.
Édition en masse avec Raw Editor
Pour migrer tout un fichier .env d'un coup, « Raw Editor » bascule vers une zone de texte brut : une paire KEY=value par ligne, les commentaires « # » ignorés. Les clés existantes gardent leurs indicateurs secret/build-time déjà définis — Raw Editor ne touche que les valeurs et les ajouts, pas ces métadonnées.
Appliquer les changements
Chaque ajout, modification ou suppression est d'abord mis en attente — rien ne prend effet avant que vous cliquiez sur « Deploy » dans la barre de changements en attente en bas (ou Discard pour abandonner le brouillon). Cette barre suit combien de changements sont en attente, donc un lot de modifications part en un seul déploiement au lieu d'un par champ.