Variables

Ever commit an API key to Git by accident? Yeah, environment variables exist to prevent exactly that.

Galaxy keeps variables encrypted and secure. They're never exposed in logs or error messages. They're the right way to handle secrets.

Why Environment Variables?

Never hardcode secrets in your code.

Never commit API keys to Git.

Never store passwords in your repository.

Environment variables exist specifically to solve this problem. Set them in Galaxy, and your app reads them at runtime. Your code stays clean, your secrets stay safe, and you can change configuration without touching code.

Meteor Apps: Galaxy Mode

Meteor apps get a specialized editing experience in the Variables tab. Look for the GALAXY MODE badge at the top of the page.

Instead of managing individual key-value pairs, you edit your complete settings.json in a dedicated JSON editor. This matches the Meteor workflow you're already used to.

The Meteor Settings Editor

The editor shows your entire settings structure:

{
  "galaxy.meteor.com": {
    "env": {
      "MONGO_URL": "mongodb://user:password@host/db",
      "MAIL_URL": "smtp://user:password@smtp.example.com:587"
    }
  },
  "packages": {
    "mongo": {
      "options": {
        "tlsAllowInvalidCertificates": true
      }
    }
  },
  "private": {
    "stripeKey": "sk_live_xxx",
    "apiSecret": "your-secret-here"
  },
  "public": {
    "appName": "My App",
    "apiUrl": "https://api.example.com"
  }
}

Edit directly in the browser. Galaxy validates your JSON as you type, catching syntax errors before you save.

Understanding Meteor Settings Structure

Your settings break down into distinct sections.

galaxy.meteor.com.env: Environment variables that Galaxy injects into your container. These become available via process.env in your server code. Common uses include MONGO_URL, MAIL_URL, ROOT_URL, and other service connection strings.

packages: Configuration for specific Meteor packages. The most common use is the MongoDB TLS setting for Galaxy's free shared cluster.

private: Server-only settings accessible via Meteor.settings in your server code. API keys, service credentials, and other secrets belong here. These never reach the client.

public: Client-accessible settings available via Meteor.settings.public in both server and client code. App names, feature flags, and public API endpoints go here.

Editing Meteor Settings

Accessing Settings in Your Code

On the server, access all settings via Meteor.settings:

// Server-side code
const stripeKey = Meteor.settings.private.stripeKey;
const mongoUrl = process.env.MONGO_URL;

On the client, only public values are available:

// Client-side code
const appName = Meteor.settings.public.appName;

Web Apps: Standard Variables

For Node.js, Python, and AdonisJS apps, the Variables tab shows a standard key-value interface. Each variable appears as a row you can edit individually.

Adding Variables

Add variables one at a time by clicking Add Variable. Type the key (the variable name) and value (what your app reads).

Key: The variable name your code looks for. Usually all uppercase with underscores, like DATABASE_URL, STRIPE_SECRET_KEY, or API_TOKEN.

Value: What your app gets when it reads this variable. The actual secret, URL, or configuration value.

Click Save to store the variable.

Editing Variables

Find the variable you want to change. Click it to edit. Update the value, click Save.

Done. Your change is saved but not yet applied.

Deleting Variables

Find the variable and click the delete icon (trash can). Confirm the deletion. The variable is removed.

Save vs Deploy

This is important. Saving and deploying are separate actions.

Save: Click Save to store your variable changes. Your running app isn't affected.

Multiple edits: Make as many variable changes as you need, saving each one. Your live app keeps running.

Deploy: When ready, click Deploy to apply all saved changes. Galaxy performs a zero-downtime rolling restart, updating your app with new variables.

This separation prevents accidents. Prepare configuration changes carefully. Only when you click Deploy does anything change.

Common Variables by Platform

Meteor Apps

{
  "galaxy.meteor.com": {
    "env": {
      "MONGO_URL": "mongodb://...",
      "MAIL_URL": "smtp://...",
      "ROOT_URL": "https://myapp.meteorapp.com"
    }
  }
}

Node.js / AdonisJS

DATABASE_URL=postgresql://user:pass@host:5432/db
REDIS_URL=redis://user:pass@host:6379
NODE_ENV=production
LOG_LEVEL=info

Python

DATABASE_URL=postgresql://user:pass@host:5432/db
SECRET_KEY=your-django-secret-key
DEBUG=False

Best Practices

Keep them secure: Never share variable values with anyone who doesn't absolutely need them. Don't paste them in chat or email.

Use strong values: For API keys and tokens, use the strongest credentials your provider offers. For passwords, use long, random strings.

Rotate sensitive values: Periodically regenerate API keys, auth tokens, and passwords. Update Galaxy with new values and redeploy.

Don't duplicate: Don't create multiple variables with similar purposes. It's confusing and error-prone. One DATABASE_URL per environment, not five variants.

Document them: Keep notes somewhere (not in code!) about what each variable is for. Future you will thank current you.

Use staging for testing: Have separate variables for staging and production. Test configuration changes in staging before applying to production.

Troubleshooting

What's Next?