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: Settings Modes

Meteor apps get a specialized settings experience in the Variables tab. At the top of the page, you'll see a Settings Mode toggle with two options: Galaxy Mode and Repository Mode.

Choosing a Mode

Galaxy Mode is the recommended option for most teams. Your settings are encrypted and stored securely in Galaxy, completely outside your repository. Even if your repo ever becomes public by accident, your secrets stay protected.

Repository Mode trades that security guarantee for Git-based versioning. It works well for non-sensitive configuration, but any secrets in your settings file live in your repository. One accidental visibility change and they're exposed.

Not sure which one to pick? Here's a quick way to think about it.

Use Galaxy Mode if:

• You want your secrets encrypted and stored outside your repository (recommended)
• You manage settings directly in the dashboard
• You deploy via the Meteor CLI (meteor deploy)
• You don't have (or don't want) a Git integration set up

Use Repository Mode if:

• You deploy via Push to Deploy (P2D) with a Git integration
• Your settings file contains only non-sensitive configuration
• Your CI/CD pipeline already manages the settings file

Galaxy Mode

In Galaxy Mode, Galaxy stores your settings and injects them into your app on every deployment. This is the default for all Meteor apps. Look for the GALAXY MODE badge at the top of the page.

You edit your complete settings.json in a dedicated JSON editor right in the dashboard. Galaxy validates your JSON as you type, catching syntax errors before you save.

The editor holds 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": {
    "paymentApiKey": "your-payment-api-key",
    "apiSecret": "your-api-secret"
  },
  "public": {
    "appName": "My App",
    "apiUrl": "https://api.example.com"
  }
}

Repository Mode

In Repository Mode, Galaxy reads your settings file directly from your Git repository snapshot captured during each Push to Deploy build. Look for the REPOSITORY MODE badge at the top of the page.

You'll see a Settings File Path field showing the path to your settings file relative to the repo root. Click the edit icon next to the path to change it.

Because settings come from your repository, there's no separate save step in the dashboard. Just update the file in your repo and push. Galaxy picks it up on the next deployment automatically.

Understanding the Settings Structure

Both modes use the same settings.json structure. Here's what each section does.

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 Settings in Galaxy Mode

Accessing Settings in Your Code

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

// Server-side code
const paymentApiKey = Meteor.settings.private.paymentApiKey;
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, PAYMENT_API_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?