.meteorapp.com` domain no longer resolves. Add a [custom domain](/docs/apps/custom-domains) beforehand if you need to avoid any interruption.
***
## What This Means for You
Galaxy Metal represents our commitment to giving you the best hosting platform possible. Faster builds mean you spend less time waiting and more time shipping features. Enhanced security means your apps are better protected. Superior performance means your users get faster response times.
And you didn't have to do anything to get these benefits. That's the whole point.
Your deployment workflow stays the same. Your code doesn't change. You just have a faster, more secure, more powerful platform underneath everything you're already doing.
Questions about Galaxy Metal infrastructure? Check out our [support page](/docs/getting-started/support) to learn how to reach us.
## What's Next?
---
# Overview Menu (https://help.galaxycloud.app/docs/dashboard/overview)
## Recent Apps
Your most recently active applications show up instantly in this section.
Each app card displays what matters for a quick status check: the app name, current status, container count, and plan tier. One glance tells you everything.
Click any app name to jump to its management page. That's where you configure deployments, scale containers, view logs, and make changes. See something stuck or unexpected? Click it and investigate.
Click "View All" for your complete app list. Useful when you have many apps and you're hunting for one that's not in the recent section.
Check Overview first when you log in. It's the fastest way to see what's running and what needs attention.
***
## Recent Databases
Similar to apps, your most recent database clusters appear here for a quick view of your data layer.
Each card shows the database name, type (MongoDB, PostgreSQL, Redis), version (like MongoDB 8.0.4), and current status. This quick glance tells you whether databases are running smoothly or need attention.
Click any database to open its management page. View connection credentials, check performance metrics, manage backups, and scale as your needs grow.
Click "View All" to browse your entire database collection. Handy when you need to find a specific one that's not in the recent list.
Database showing "Provisioning" or "Failed"? Click into it to see what's happening. Logs and details are right there.
***
## Making the Most of Overview
Overview is your jumping-off point, not your command center. Use it to get oriented when you log in and spot anything needing attention.
Notice an app or database with an unusual status? That's your signal to click in and investigate. Status changes often signal something important, and logs explain why.
The beauty of Overview? It shows you what matters in seconds. You don't need to be a Galaxy expert to scan this page and know what's running, what's stopped, and whether anything looks wrong.
***
## What's Next?
---
# Security Menu (https://help.galaxycloud.app/docs/dashboard/security)
The Security section only appears for personal accounts. In an organization, you'll see the [Members menu](/docs/dashboard/members) instead.
## Two-Factor Authentication
Two-factor authentication (2FA) adds a crucial second layer of protection. Even if someone gets your password, they can't access your account without the second verification. It's the single most important thing you can do to protect your account.
Don't skip 2FA. Set it up as soon as you create your account.
2FA isn't optional if you care about security. We strongly recommend setting it up immediately.
***
## Choose Your 2FA Method
### The Gold Standard
Use an app like Google Authenticator, Authy, or Microsoft Authenticator.
**How it works:**
1. Click "Enable App 2FA"
2. Galaxy shows you a QR code
3. Open your authenticator app and scan it
4. Your app generates a new 6-digit code every 30 seconds
5. When logging in, enter your password, then the current code
Only you can generate valid codes unless someone has physical access to your phone.
**Why this is the best option:**
* Codes generated on your phone with no network dependency
* Even if Galaxy's servers are compromised, your codes stay secure
* Time-based codes make brute force attacks impossible
* You maintain complete control
**Recovery codes:**
When you enable App 2FA, Galaxy gives you recovery codes. These backup codes work if you lose access to your authenticator app (like getting a new phone). Store them somewhere safe and separate from your phone, like a password manager.
Save recovery codes in a password manager. Keep them separate from your phone so you can access them even if your phone is lost.
Toggle App 2FA on and off anytime. Switching phones? Disable it on the old device and set it up fresh on the new one.
### Alternative Option
Email 2FA is available if you can't use an authenticator app, but it's less secure.
**How it works:**
1. Click "Enable Email 2FA"
2. When logging in, Galaxy sends a code to your email
3. Check your email, copy the code, enter it
**Why it's less secure:**
* Your email itself could be compromised
* Email delivery isn't instant
* An attacker controlling your email can intercept codes
**But still better than no 2FA:**
* Much better than just a password
* Simple and straightforward
* Works as a backup if something happens to your authenticator app
You can enable both App 2FA and Email 2FA at the same time for redundancy. If one method breaks, you have a backup.
Consider enabling both methods for maximum security. If one breaks, you have a backup.
***
## Updating Your Password
Your password is your first line of defense. Keep it strong and change it regularly.
On the right side of the Security page, you'll see a password update form. Enter your current password (to confirm it's you), your new password, and confirm. Click "Update Password" and it's done immediately.
### Making a Strong Password
Your password should be:
* At least 12 to 16 characters long
* Mix of uppercase, lowercase, numbers, and symbols
* No personal information (names, birthdays, addresses)
* No dictionary words or obvious patterns
* Different from other accounts
* Never reused
**Bad:** `password123`
**Good:** `Gx$7mK@nP2qL9wR#vY`
Use a password manager like 1Password, LastPass, or Bitwarden. They generate strong passwords and remember them. You only need one master password.
### When to Change Your Password
* Regularly (every few months)
* Immediately if you suspect someone has access
* After major security events (adding or removing 2FA)
* Never reuse old passwords
Use a password manager. Easier and more secure than creating passwords yourself.
***
## If Your Account Is Compromised
Suspect someone has access? Act fast.
1. Change your password immediately
2. Check your 2FA setup is still configured correctly
3. Review recent login activity if available
4. Check apps and databases for unauthorized changes
5. Contact support if something looks wrong
Don't panic. Galaxy's security features limit what an attacker can do. If you have 2FA enabled, they can't access your account even with your password.
***
## Security Best Practices
**Use a password manager** to generate and store all passwords. Unique and complex, every time.
**Enable 2FA on your email address.** Your email is how you recover all your other accounts. Protect it.
**Never share your Galaxy login** with anyone, even team members. Use Organizations for team collaboration instead.
**Logout on shared computers.** Coffee shop, library, shared office? Always logout when done.
**Keep devices updated** with latest security patches. This applies to phone, computer, and authenticator apps.
**Watch account activity.** Login attempts from unfamiliar locations or strange times? Change your password immediately.
***
## Common Questions
Authenticator app is more secure. Use Email 2FA only if you can't use an authenticator app. You can enable both for redundancy.
Use your recovery codes to log in. That's why it's critical to store them somewhere safe and separate from your phone.
Yes, you can toggle it off anytime. But we don't recommend it, your account is less secure without 2FA.
Every few months, or immediately if you suspect it's compromised. Use a password manager to make this easy.
At least 12-16 characters, mix of uppercase, lowercase, numbers, and symbols. No dictionary words, personal info, or patterns.
Use the "Forgot Password" link on the login page. Galaxy sends a reset link to your email.
When you sign up via Google or GitHub, no Galaxy password is created for your account. To set one, go to the login page and click "Forgot Password". Enter the email address associated with your Google or GitHub account and Galaxy will send you a password reset link. Follow the link to create a password. After that, you can log in with either your social account or your new email and password.
***
## What's Next?
---
# Settings Menu (https://help.galaxycloud.app/docs/dashboard/settings)
The Settings page changes depending on what you have selected in the account switcher at the top of the dashboard. Personal accounts show profile management. Organizations show organization configuration.
## Account Details
Your username and email address identify you on Galaxy.
**Username** is displayed at the top. This is your unique identifier. You use it to log in, it shows up in your profile, and it's how organization admins find you when adding members.
Here's the catch: your username is locked once your account is created. Can't change it later. If you absolutely need a different username, you'd have to create a new account (but that means losing current apps and databases). Pick something you won't regret.
**Primary email address** is shown below your username. Galaxy uses it for password reset links, account recovery, important notifications, and billing communications. If this email changes (switching providers, for example), update it here so you don't lose access.
***
## Email Management
You can have multiple email addresses on your account. Useful for switching providers, having a backup for recovery, or separating work and personal emails.
### Adding an Email
Click "Add New Email" to add another address. Galaxy sends a verification link. Click the link to confirm you own it.
If verification doesn't arrive:
* Check your spam folder
* Wait a moment and refresh the page
* Request verification again from the Settings page
Once verified, the email is ready to use.
### Setting Your Primary Email
Your primary email handles password resets and important communications. Change which email is primary anytime by clicking "Set as primary" next to any verified email.
Only verified emails can be set as primary. Pending emails show a "Verify" button to send another verification.
### Removing an Email
Click "Remove" next to any email. You need at least one address on your account.
Set up a backup email if possible. If you lose access to your primary, a verified backup can help you regain access.
***
## Incoming App Transfers
When someone transfers an app to your account, the request lands here under **Incoming App Transfers**. Each pending request shows the app name and the account it came from, with **Accept** and **Reject** next to it.
Accept and Galaxy starts preparing the app in your account. Reject and the app stays with the sender.
You'll also see a banner at the top of any dashboard page while a request is waiting. Click **Review transfer** on the banner to handle it without coming to this page.
Only the account owner can review incoming transfers. Everyone else sees a note explaining that.
An accepted app arrives with its configuration and domains, and the sending account loses its credentials and access to it. Confirm with the sender before accepting anything you weren't expecting.
Sending an app to someone else works from the app's own Settings page. See [Transfer an App](/docs/apps/transfer-apps) for that side of the flow.
***
## Stopping Your Account
Want to stop using Galaxy? Two options.
### Pausing Your Account
Might come back later? Consider stopping your apps instead of canceling. Galaxy doesn't charge for inactive or deleted apps. Stop everything, let your account sit dormant, re-enable whenever you're ready.
### Canceling Entirely
Sure you want to leave? You can close your account completely. Click "Contact Support" from the Settings page and the team walks you through cancellation. They'll explain what happens and answer questions.
**Before you cancel:**
* Export important data from databases
* Make sure application code is backed up (Git repository or locally)
* If unsure, consider just stopping apps and keeping account dormant
* Support team can help with questions about the process
Cancellation is permanent. Once you cancel and data is deleted, it's gone. Be absolutely sure before confirming.
## Organization Details
When you select an organization in the account switcher, the Settings page shows organization-specific information.
**Organization name** appears at the top. This is the organization's unique identifier across Galaxy. Like personal usernames, organization names are locked once created.
**Owned by** shows who created and owns the organization. The owner has full control and is the only one who can transfer ownership or close the organization entirely.
Assigning roles and managing who's on the team happens in the [Members Menu](/docs/dashboard/members). This page covers organization details, billing permissions, and ownership.
***
## Billing Management
This is where things get interesting for teams. You can control who manages billing for the organization.
Two options:
* **Any Organization Member**: Everyone in the organization can view and manage billing settings, update payment methods, and access invoices
* **Only Organization Owner**: Billing access is restricted to the organization owner only
Only the organization owner can change this setting. Everyone else sees it as read-only.
Choose based on your team structure. Small teams might be fine with open billing access. Larger organizations often prefer restricting it to the owner for tighter financial control.
Running a company account? "Only Organization Owner" keeps billing details private from developers who just need to deploy apps.
***
## Transfer Ownership
Every organization has exactly one owner. When you need to hand that off, do it right from this page.
Under **Transfer Ownership**, pick the new owner from the member dropdown and click **Change Ownership**. Confirm the prompt, and the role moves over. You stay on as a member of the organization afterward.
Only the current owner can transfer ownership. If you don't own the organization, you won't see this control.
Once you confirm, the selected member becomes the owner with full control, including the ability to transfer ownership again or close the organization. Hand off only to someone you trust.
***
## Incoming App Transfers
Apps sent to the organization show up here under **Incoming App Transfers**, with the app name, the source account, and **Accept** and **Reject** buttons. A banner at the top of any dashboard page points to the same requests while they're pending.
Only the organization owner can accept or reject. Admins, developers, and viewers see a note instead of the buttons, even though they can open this page.
An accepted app arrives with its configuration and domains, and the sending account loses its credentials and access to it. Confirm with the sender first.
To move an app out of the organization, use the Transfer App control on the app's own Settings page. See [Transfer an App](/docs/apps/transfer-apps).
***
## Closing an Organization
Want to stop billing for the organization? You have options.
### Just Stop the Apps
Galaxy doesn't charge for inactive or deleted apps. If you want to pause without losing access, simply stop all your apps and databases. The organization stays active but costs nothing.
### Close Entirely
Ready to shut everything down? Click "Contact Support" and the team walks you through it. They'll help you understand what happens to apps, databases, and member access.
**Before closing:**
* Export all database data you need to keep
* Make sure all application code is backed up
* Let team members know (they'll lose access)
* Consider just stopping resources if you might return
Closing an organization is permanent. All apps, databases, and member associations are deleted. Be certain before confirming.
***
## API & Integrations
The Settings sidebar splits into two groups. **General** holds the account or organization details covered above, and **API & Integrations** holds two pages that work the same way for personal accounts and organizations.
**Authorized Domains**: The domain whitelist for apps that use Meteor as an identity provider.
**Public API**: Scoped credentials for server-to-server automation. Each credential is locked to the applications and capabilities you pick, and you can rotate or revoke it whenever you need to. It's available for Meteor apps on the Professional and Custom plans, and the [Public API article](/docs/apps/meteor/api) walks through the whole setup.
Only the account owner, or an owner or admin of the organization, can manage Public API credentials. Developers and viewers don't see the page.
***
## Pro Tips
**Keep your email current.** Change your email provider? Update it in Galaxy too. Don't let them get out of sync.
**Use a stable recovery email.** If possible, use an email unlikely to change (like a Gmail you'll keep forever) as recovery. Lifeline if you ever lose primary access.
**Verify your backup email.** Having a second verified email means you're not locked out if you lose primary access. Worth setting up.
**Review settings occasionally.** Every few months, check Settings to make sure everything is current. Email addresses change, life happens.
**Don't share your account.** Not even with team members. Use organizations for collaboration. Keeps your credentials safe while letting others work on the same resources.
**Match billing permissions to your team.** Small team where everyone handles finances? Open billing access is fine. Larger team with dedicated finance people? Restrict it to owners.
***
## Common Questions
No, usernames are locked once your account is created. If you absolutely need a different username, you'd have to create a new account (losing current apps and databases).
No, organization names are locked once created. If you need a different name, you'd have to create a new organization and transfer resources.
There's no limit. Add as many as you need for backup, work, personal, etc.
Check your spam folder, wait a moment and refresh the page, or request verification again from the Settings page.
The owner can do it from this page. Under Transfer Ownership, pick a member, click Change Ownership, and confirm. The previous owner stays on as a member.
In the Incoming App Transfers section on this page, or from the banner that appears at the top of any dashboard page while a request is pending. Only the account owner sees the Accept and Reject buttons.
Pausing means stopping your apps but keeping your account. Canceling means closing your account permanently. Pausing is reversible; canceling is not.
Only the organization owner can change whether billing is open to all members or restricted to the owner.
The account owner for a personal account, or an owner or admin for an organization. Developers and viewers can't create, rotate, or revoke credentials, and neither can an impersonated session.
Yes, if their role allows it. Billing permissions only affect access to payment methods, invoices, and billing settings. What a member can do with apps depends on their role, not the billing setting.
***
## Security Reminders
Settings handles profile stuff. Account security happens in a different section. Keep these in mind:
**Change password regularly.** In the [Security Menu](/docs/dashboard/security). Strong password changed occasionally is your first defense.
**Keep 2FA enabled.** Should be active in your Security menu. Adds crucial second layer of protection.
**Verify recovery emails.** Make sure backup emails are actually verified and working. Test occasionally.
***
## What's Next?
---
# Database Backups (https://help.galaxycloud.app/docs/databases/backup)
## How Backups Work
Galaxy creates automatic daily backups of every database. Think of them as snapshots in time. If data gets corrupted, deleted, or something breaks, you can restore from any backup point.
Every database automatically gets backups with no setup required. They just happen in the background while you sleep.
All Galaxy databases include automatic daily backups with a 4-day retention period at no extra cost.
***
## Standard Backups
Every database includes automatic daily backups automatically. No cost, no configuration needed.
**Retention:** 4 days
**Cost:** Included with your plan
**Backups per day:** 1 (daily backup)
Perfect for most use cases. If something breaks today, you can restore from up to 4 days ago. For most scenarios, that's plenty of time to catch and fix problems.
If you need to keep backups beyond 4 days for compliance or business reasons, check out the [Extended Backup Retention guide](/docs/databases/extended-backup).
***
## Backup Timing and Schedule
Backups run automatically every day during a consistent window. Understanding when they run helps you plan around large data imports or maintenance.
### Backup Window
Daily backups run between **03:00 and 05:00 UTC** by default. That's the timeframe when Galaxy creates your backup snapshot.
The exact time within that window can vary, but backups always happen during those two hours. If you run large data operations, avoid that window to prevent impact on your application.
### Want a Different Time?
If the 03:00 to 05:00 UTC window doesn't work for your schedule, contact support. We can often arrange a custom backup window that aligns with your needs.
Just mention your preferred time when you reach out, and we'll see what we can do.
***
## Logs and Metrics
Beyond backups, Galaxy also retains logs and performance metrics for troubleshooting and analysis.
### What's Retained
**Logs:** Up to 10,000 lines of database activity logs are kept. Useful for debugging queries, finding errors, and understanding what happened during a specific time period.
**Metrics:** Performance data like CPU, memory, connections, and disk usage are retained for one full calendar month. After that, older metrics are automatically removed.
You can access both logs and metrics from your database's dashboard in Galaxy. Click into any database, then look for the Logs or Metrics sections.
If you delete your database, both logs and metrics are automatically deleted along with it. Backups remain available according to your retention policy, but the database-level logs and metrics are gone.
***
## Downloading Backups
Need your data back? Galaxy makes backups available for download so you can restore them yourself.
From your database's Backups section in the Galaxy dashboard, you'll see a list of all available backups with their dates and sizes. Select the backup you need and download it. You can then restore the data to your database using your database tool's import features.
This gives you full control over when and how you restore data.
***
## Common Questions
Check your database's Backups section in the Galaxy dashboard. You'll see a list of all backups with their status (Success, In Progress, Failed). Each entry shows when it ran and how large it is.
Yes. From your database's Backups section, select a backup and look for a download option. This lets you store a copy offline or migrate to another system.
Absolutely, as long as a backup was created after your data was added but before you deleted it. Download the appropriate backup from your Backups section and restore it using your database tool's import features.
Backups run during the scheduled window and use dedicated resources. They don't significantly impact your app's performance, but if you notice slowness during backup hours, reach out to support to explore custom timing.
Yes. All backups are encrypted and stored securely using the same security standards as your live database.
Backups continue for your retention period. Once your retention period expires, old backups are deleted automatically. If you want to keep specific backups longer, extend your retention period.
Yes. Any backups still within your new retention period stay available. Extended retention applies to all existing and future backups.
Good question. It's smart to test a restore every few months to make sure your backup strategy actually works when you need it. You'll feel more confident knowing recovery works.
***
## Backup Best Practices
**Keep your retention period realistic.** More retention means higher costs. 4 days covers most accidental deletions. Extend beyond that only if you really need long-term protection.
**Test restores occasionally.** Don't assume backups work until you've tested a restore yourself. Verify your recovery procedure works before you actually need it.
**Combine with your own backups.** Database backups are great, but consider maintaining your own backup outside Galaxy for critical data. Defense in depth is always smart.
**Review backup needs regularly.** As your data grows, backup costs increase. Check quarterly whether you actually need extended retention or if you can scale back.
**Download important backups.** For mission-critical data, download backups and store them somewhere secure and separate from Galaxy.
***
## What's Next?
***
## Still Have Questions?
Backups are critical infrastructure, and we want you to feel confident they're protecting your data. If you have questions about your specific backup setup, [reach out to support](/docs/getting-started/support). We're here to help make sure your data is safe.
---
# Connect Your Database with TablePlus (https://help.galaxycloud.app/docs/databases/connect)
# TablePlus
Want to visually browse your Galaxy database without writing SQL? TablePlus is a slick database manager that works with MongoDB, PostgreSQL, Redis, and more. It's the easier way to poke around your data.
This guide gets you connected in just a few minutes.
***
## Before You Start
You'll need:
* Access to your Galaxy dashboard
* A database already provisioned on Galaxy (MongoDB, PostgreSQL, or Redis)
* TablePlus installed on your computer
* An internet connection
Don't have TablePlus yet? Download it from the [official site](https://tableplus.com/download/) for your operating system. It's available for Mac, Windows, and Linux.
TablePlus is free to download and use. They offer a paid version with extra features, but the free version works great for connecting to Galaxy databases.
***
## Get Your Connection Details
Your Galaxy database connection credentials are right in your dashboard. Here's where to find them.
### Log Into Galaxy
Head to your [Galaxy dashboard](https://my.galaxycloud.app).
### Navigate to Databases
Click **Databases** in the sidebar menu.
### Select Your Database
Find the database you want to connect to and click on its name.
### Copy the Credentials
Scroll to the **Credentials** section. You'll see three important pieces:
* **Username**: Your database user
* **Password**: Your database password
* **Connection String**: The complete URL you'll paste into TablePlus
Copy that connection string (it looks something like `mongodb://user:pass@host:27017/dbname?ssl=true`). You'll need it in the next step.
That connection string contains your password. Keep it secure. Don't commit it to Git, don't paste it in chat, don't leave it lying around.
***
## Connect TablePlus to Your Database
Now open TablePlus and point it at your Galaxy database.
### Launch TablePlus
Open the TablePlus application on your computer.
### Create a New Connection
Click **Create a New Connection** on the welcome screen, or go to **Connection > New > Connection** in the menu.
### Pick Your Database Type
TablePlus shows you a list of database types. Find the one matching your Galaxy database (MongoDB, PostgreSQL, Redis, etc.) and select it.
Look for an **Import from URL** button. Click it.
### Paste Your Connection String
A dialog appears asking for a URL. Paste that connection string you copied from Galaxy earlier. The full URL should look something like:
```
mongodb://your_user:your_password@host.region.galaxy.mongodb.net:27017/dbname?ssl=true
```
Then click **Import**.
### Verify and Save
TablePlus automatically parses the URL and fills in the connection fields: host, port, username, password, database name, and SSL settings. Everything should be populated correctly.
Give your connection a friendly name if you want (like "Production MongoDB" or "Galaxy Dev Database"). This makes it easier to find later if you have multiple databases.
Click **Test** to verify the connection works. If it connects, you're good to go. Click **Save** and you're done.
Connected? You now have direct visual access to your database. Browse tables, run queries, and manage data without touching the command line.
***
## What You Can Do Now
Once connected, TablePlus gives you full visual access to your database:
* **Browse tables and collections**: See your data structure at a glance
* **Run queries**: Write and execute SQL or database-specific commands
* **Edit data**: Update records directly from the table view
* **Manage schema**: Modify tables, add columns, create indexes (depending on database type)
* **Export data**: Pull data out for backups or migration
***
## Keeping It Secure
Your database connection is as secure as your computer and the connection credentials you're using. A few things to keep in mind:
**Never share your connection string.** It includes your password. If someone gets it, they get full access to your database.
If you accidentally expose your connection string, change your database password immediately from the Galaxy dashboard. Don't wait.
**Keep TablePlus updated.** Security patches matter. Check for updates regularly in TablePlus settings.
**Use strong database passwords.** Long, complex, unique. If you inherited a weak password, change it.
**Review access regularly.** In the Galaxy dashboard, check which users have access to your database. Remove users who no longer need it.
***
## Troubleshooting
**Connection times out?** Make sure your database is running (check the Galaxy dashboard). Also verify the connection string is exactly right, especially the host, port, and database name.
**"Authentication failed" error?** Double-check your username and password. Spaces, special characters, and case sensitivity all matter. If you're not sure, reset your database password in the Galaxy dashboard and use the new one.
**Can't find Import from URL?** Different versions of TablePlus have slightly different UIs. Look for an option to paste a connection URL, or manually fill in the host, port, username, password, and database name fields instead.
**Still stuck?** [Reach out to Galaxy support](/docs/getting-started/support). We can help verify your connection details and troubleshoot connection issues.
***
## What's Next?
---
# Database Plans (https://help.galaxycloud.app/docs/databases/database-plans)
Galaxy manages your databases so you don't have to. Pick the plan that fits your current needs and scale up as your app grows. All plans include monitoring and daily backups.
## MongoDB
MongoDB on Galaxy is available in two deployment modes: **Standalone** (single node, great for most apps) and **Replicaset** (three nodes for high availability and automatic failover).
Every Meteor app on the Free Plan includes a shared MongoDB cluster at no cost. It's great for testing and early development.
| Plan | RAM | CPU | Storage |
| -------- | ------ | ------- | ------- |
| Basic | 512 MB | 0.5 ECU | 5 GB |
| Starter | 1 GB | 1 ECU | 10 GB |
| Standard | 2 GB | 2 ECU | 15 GB |
| Pro | 4 GB | 4 ECU | 30 GB |
| Premium | 8 GB | 4 ECU | 60 GB |
| Plus | 16 GB | 6 ECU | 100 GB |
| Ultra | 32 GB | 12 ECU | 180 GB |
| Plan | RAM | CPU | Storage |
| -------- | ------ | ------- | ------- |
| Basic | 512 MB | 0.5 ECU | 5 GB |
| Starter | 1 GB | 1 ECU | 10 GB |
| Standard | 2 GB | 2 ECU | 15 GB |
| Pro | 4 GB | 4 ECU | 30 GB |
| Premium | 8 GB | 4 ECU | 60 GB |
| Plus | 16 GB | 6 ECU | 100 GB |
| Ultra | 32 GB | 12 ECU | 180 GB |
**Standalone** works well for most apps in development. **Replicaset** is the right call when you can't afford downtime: it keeps three synchronized nodes running, so a failure on one doesn't take your database offline.
***
## Redis
Redis is Galaxy's in-memory data store, built for caching, session management, and real-time workloads. It's fast by design.
| Plan | RAM | CPU | Storage |
| -------- | ------ | ------- | ------- |
| Basic | 512 MB | 0.5 ECU | 5 GB |
| Starter | 1 GB | 1 ECU | 10 GB |
| Standard | 2 GB | 2 ECU | 15 GB |
| Pro | 4 GB | 4 ECU | 20 GB |
| Premium | 8 GB | 4 ECU | 30 GB |
| Plus | 16 GB | 6 ECU | 40 GB |
| Ultra | 32 GB | 12 ECU | 50 GB |
**Basic** covers most caching scenarios for small apps. Go **Pro** or above if you're storing large datasets in memory or running high-throughput pub/sub workloads.
***
## PostgreSQL
PostgreSQL on Galaxy gives you a fully managed relational database with the same flexible sizing as the rest of the platform.
| Plan | RAM | CPU | Storage |
| -------- | ------ | ------- | ------- |
| Basic | 512 MB | 0.5 ECU | 5 GB |
| Starter | 1 GB | 1 ECU | 10 GB |
| Standard | 2 GB | 2 ECU | 15 GB |
| Pro | 4 GB | 4 ECU | 30 GB |
| Premium | 8 GB | 4 ECU | 60 GB |
| Plus | 16 GB | 6 ECU | 100 GB |
| Ultra | 32 GB | 12 ECU | 180 GB |
**Standard** is a solid baseline for most relational workloads. Step up to **Pro** or **Premium** when you're handling complex queries, heavy joins, or larger datasets.
***
## What's Next?
---
# Extended Backup Retention (https://help.galaxycloud.app/docs/databases/extended-backup)
Galaxy takes daily backups automatically and keeps them for 4 days at no extra cost. Extended retention lets you keep those backups for longer: 15 days, 30 days, or a custom period.
***
## What It Costs
Extended retention is billed at **US$ 0.06 per GB per day** for storage beyond the standard 4-day window. The charge is based on your allocated database size, not how much data you're currently storing.
**Formula:** `allocated size (GB) × extra days × $0.06`
| Database size | Retention | Extra days | Monthly cost |
| ------------- | --------- | ---------- | ------------ |
| 10 GB | 14 days | 10 | US$ 6.00 |
| 5 GB | 30 days | 26 | US$ 7.80 |
| 20 GB | 30 days | 26 | US$ 31.20 |
Charges are pro-rated from the date you enable it and appear as a line item on your next invoice.
If you allocated 50 GB but only use 20 GB, extended retention charges you for 50 GB. Galaxy reserves backup storage at full capacity.
***
## How to Request It
Contact [Galaxy Support](/docs/getting-started/support) via live chat or email. Include:
* Your database name
* How long you want to keep backups (15 days, 30 days, or a specific number)
Support confirms the cost and enables it immediately. No disruption to your database or existing backups.
***
## Restoring From an Extended Backup
Restoring from a backup older than 4 days requires contacting support. They extract the backup and send you a secure database dump file. You then import it using your database tool.
When you reach out, include:
* Your database name
* The specific backup date you need
* Your database region
* Whether you're restoring to production or staging
***
## Common Questions
Yes. Extended retention is per-database. Leave others on standard 4-day retention and only pay for what you need.
Yes. You're not limited to 15 or 30 days. Tell support your exact requirement (7 days, 60 days, 90 days) and they'll set it up.
Yes. Contact support to update it. Changes take effect immediately and costs adjust on your next billing cycle.
Backups older than your new retention period are deleted automatically on their expiration dates. No immediate deletion; just a different schedule going forward.
Yes. Extended retention is based on allocated size. If you scale up your database allocation, retention costs scale with it.
Probably not. Standard 4-day retention covers most accidental deletion scenarios. Use extended retention where you have a compliance requirement, a regulatory mandate, or a specific business need.
Each backup gets its own window from its creation date. With 14-day retention, a backup created on day 1 is kept until day 14. A backup created on day 2 is kept until day 15. No overlap.
***
## What's Next?
---
# Fair Usage Policy for Free MongoDB (https://help.galaxycloud.app/docs/databases/free-mongodb-fair-usage)
## What You Need to Know
Galaxy offers a free MongoDB database to help you prototype, learn, and build personal projects. We love supporting developers getting started, but to keep things sustainable for everyone, there are some boundaries.
Think of it like this: the free tier is your sandbox. It's perfect for learning, testing ideas, and shipping personal projects. It's not meant for production apps or commercial services.
## The Key Limits
**Data storage:** You get up to 256MB of storage on the free tier. That's plenty for most prototypes and learning projects. If you're building something bigger, that's a signal to upgrade to a paid database, which gives you way more space and resources.
**Uptime expectations:** We don't guarantee the same reliability for free databases as we do for paid tiers. Your free database might experience occasional downtime. If uninterrupted service is critical for you (running a business, hosting a customer app), you'll want to move to a paid plan.
**What it's for:** Learning, prototyping, testing, personal projects. Not commercial use. If you're earning money from your app or using it for a business, upgrade to a paid tier. It's genuinely affordable and way more reliable.
## Finding Your Free Database
When you deploy a new app and enable **Add Free MongoDB**, Galaxy links the database directly to that app. It shows up in the **Databases** tab of your dashboard alongside paid instances, so you can check its status and credentials without digging through app settings.
A few things worth knowing about this:
* The database shares the app's lifecycle. Delete the app, and the database goes with it.
* This only applies to databases created through the **Add Free MongoDB** toggle during deployment. Free databases provisioned before this feature was introduced won't appear in the **Databases** tab retroactively.
* If you don't see an older free database there, it may still be active and reachable via the `MONGO_URL` in your app's environment. It just predates dashboard visibility support.
## What's Not Allowed
There are a few activities we explicitly don't allow on the free tier, even if you somehow stay under your storage limit:
* Cryptocurrency mining or blockchain operations
* Any behavior that significantly strains shared resources, even if it technically fits the numerical limits
We reserve the right to review your usage and restrict access if something looks out of line with typical use cases.
## Next Steps
Not sure if you need to upgrade? Check how much storage you're actually using in your Galaxy dashboard. If you're running low or need production reliability, [explore our paid database options](/docs/billing/database).
Already on the free tier and running great? Perfect. Keep building. And if you hit the limits, upgrading is super straightforward.
---
# Databases (https://help.galaxycloud.app/docs/databases)
# Databases on Galaxy
Galaxy hosts MongoDB, PostgreSQL, and Redis alongside your applications. No setup hassle, no management overhead, no data transfer fees between your app and database. Create a database and connect it to your app in minutes.
Your apps and databases live together on Galaxy. Zero charges for data moving between them.
***
## Pick Your Database
Choose the database that fits your needs. Not sure? Start with PostgreSQL for most apps, MongoDB for flexible data structures, Redis for caching.
***
## Creating a Database
Head to your [Galaxy dashboard](https://my.galaxycloud.app), go to Databases, and click "Create Database". Pick your database type, choose a size and region, and Galaxy provisions it in minutes.
Once running, click your database to get the connection string. Add it as an environment variable in your app's settings, and you're connected.
Pick the same region as your app for fastest performance. Same-region traffic is also free.
***
## Features
All Galaxy databases include:
**Automatic daily backups**: Restore if something goes wrong. Your data is protected without extra configuration.
**Zero data transfer fees**: Data moving between your app and database is free. No surprise charges.
**Monitoring and metrics**: Understand what's happening with your database. Track connections, memory, CPU, and more.
**Encryption in transit**: Data stays secure as it moves between your app and database.
***
## Common Questions
PostgreSQL for most applications: it's reliable, structured, and powerful. MongoDB if your data structure changes frequently or you're building content-heavy apps. Redis for caching, sessions, and real-time features (use alongside a primary database, not instead of one).
Daily automatic backups are included with all databases. You can also create manual backups anytime from your database's settings.
Pricing depends on database type and instance size. See the [Billing section](/docs/billing/database) for complete pricing.
Yes. Create as many as you need. Each database is billed separately based on its size and type.
Yes. Use the connection string from your dashboard to connect tools like TablePlus, pgAdmin, MongoDB Compass, or any database-compatible client. See [Connect with TablePlus](/docs/databases/connect) for a guide.
***
## What's Next?
---
# Migrate to Galaxy MongoDB (https://help.galaxycloud.app/docs/databases/mongodb-migration)
Moving your existing MongoDB database to Galaxy doesn't have to be painful. Galaxy provides a Docker image that handles the data transfer for you, so you can focus on getting your app running instead of wrestling with migration scripts.
**What you'll need**:
* Docker installed on your machine
* Source and target MongoDB URIs ready and tested
* IP whitelist configured on MongoDB Atlas if that's your current host
This migration method doesn't support MongoDB Sharded Clusters. If you're running a sharded cluster, contact the Galaxy team for help.
***
## Run the Migration
### Get Your MongoDB URIs
You'll need two connection strings: one for the source and one for the destination.
Your **source URI** comes from your current MongoDB provider (for example, MongoDB Atlas) and looks like:
```
mongodb+srv://:@
```
Your **target URI** comes from the Galaxy Database team. Find it in the **Credentials** section of your database in the Galaxy dashboard. It looks like:
```
mongodb://:@:
```
### Run the Docker Container
With both URIs ready, run the migration container:
```bash
docker run --rm \
-e SOURCE_URI="" \
-e TARGET_URI="" \
-e DB_NAME="example_source_db_name" \
meteor/galaxy-mongodb-migrate:202506181938
```
Replace `SOURCE_URI`, `TARGET_URI`, and `DB_NAME` with your actual values.
Here's a complete example:
```bash
docker run --rm \
-e SOURCE_URI="mongodb+srv://username:password@source-cluster.mongodb.net" \
-e TARGET_URI="mongodb://username:password@destination-host-01.mongodb.net:27017,destination-host-02.mongodb.net:27017,destination-host-03.mongodb.net:27017/admin?replicaSet=replicaSetName" \
-e DB_NAME="example_source_db_name" \
meteor/galaxy-mongodb-migrate:202506181938
```
***
## SSL Configuration
If your Galaxy Database has SSL enabled, the connection string needs a couple of specific adjustments to work correctly.
Three things to keep in mind:
* **Always include `authSource=admin`** in your target URI. Without it, MongoDB tries to authenticate against the wrong database and the connection fails.
* **Omit `ssl=true`** from the connection string unless you're also providing a certificate file.
* If `ssl=true` is required, download the SSL certificate from the Galaxy Database dashboard and provide it through the appropriate parameter.
```bash
docker run --rm \
-e SOURCE_URI="mongodb+srv://username:password@source-cluster.mongodb.net" \
-e TARGET_URI="mongodb://username:password@destination-host-01.mongodb.net:27017,destination-host-02.mongodb.net:27017,destination-host-03.mongodb.net:27017/admin?authSource=admin&replicaSet=replicaSetName" \
-e DB_NAME="example_source_db_name" \
meteor/galaxy-mongodb-migrate:202506181938
```
Download the SSL certificate from your Galaxy Database dashboard first, then mount it into the container:
```bash
docker run --rm \
-v /path/to/ssl-cert.pem:/ssl-cert.pem \
-e SOURCE_URI="mongodb+srv://username:password@source-cluster.mongodb.net" \
-e TARGET_URI="mongodb://username:password@destination-host-01.mongodb.net:27017,destination-host-02.mongodb.net:27017,destination-host-03.mongodb.net:27017/admin?authSource=admin&ssl=true&sslCAFile=/ssl-cert.pem&replicaSet=replicaSetName" \
-e DB_NAME="example_source_db_name" \
meteor/galaxy-mongodb-migrate:202506181938
```
***
## Post-Migration: Create a Dedicated User
Once your data is in Galaxy, create a new database user scoped specifically to your migrated database. This is better security practice than connecting with your admin credentials.
### Complete the Migration First
Make sure all data has been successfully transferred to Galaxy before creating any new users.
### Connect to Your Database
Connect to your Galaxy Database using [MongoDB Compass or another client](/docs/databases/connect). Use the admin credentials from your Galaxy dashboard.
### Select the Migrated Database
Switch to the database you just migrated:
```javascript
use example_db_name
```
### Create the New User
Create a user with `readWrite` access to that specific database:
```javascript
db.createUser({
user: "newuser",
pwd: "",
roles: ["readWrite"]
})
```
Replace `` with a strong, unique password.
### Verify the User
Confirm the user was created successfully:
```javascript
db.getUsers()
```
### Update Your App's Connection String
Use the new user credentials in your app's `MONGO_URL`:
```
mongodb://newuser:pass@destination-host-01.mongodb.net:27017,destination-host-02.mongodb.net:27017,destination-host-03.mongodb.net:27017/example_db_name?replicaSet=NameOfYourReplicaSet&readPreference=secondary
```
Update this value in your app's **Variables** section in the Galaxy dashboard.
Giving your app user only `readWrite` on its own database limits the blast radius if credentials are ever compromised. Don't connect production apps with admin credentials.
***
## Security Considerations
A few practices to keep in mind after migration:
* Use secure passwords for all database users.
* Assign only the permissions each user actually needs.
* Review user privileges regularly and remove access that's no longer needed.
***
## System Users
Galaxy automatically creates several users in your MongoDB cluster for internal operations. Don't delete them or your database management will break.
**`admin@admin`**: Initial user with administrative privileges.
**`galaxyadmin@admin`**: Technical user required for automation.
**`galaxybackup@admin`**: Designated user for performing backups.
**`galaxymonitor@admin`**: Used for monitoring.
***
## Troubleshooting
If the migration fails or the connection is refused:
* Check that your connection strings are correct and that the credentials have the necessary permissions.
* Review the Docker container logs for specific error messages.
***
## Common Questions
No. This Docker image doesn't support sharded clusters. Reach out to the Galaxy team at [support@meteor.com](mailto:support@meteor.com) and we'll help you plan a migration that works for your setup.
This migration method copies data but doesn't handle live sync, so there will be a brief window where writes to the source aren't reflected in the destination. For zero-downtime migrations, contact the Galaxy team to discuss options.
`authSource=admin` tells MongoDB which database to authenticate your credentials against. Galaxy databases store user credentials in the `admin` database. Without this parameter, the driver tries to authenticate against your app's database and the connection fails.
Open your database in the Galaxy dashboard and look in the **Credentials** or **Settings** section. You'll find a download option for the SSL certificate there.
Setting up an oplog user is a separate process. Follow the [MongoDB Oplog Setup guide](/docs/databases/mongodb-oplog-setup) for step-by-step instructions.
***
For zero-downtime migrations or anything more complex, reach out at [support@meteor.com](mailto:support@meteor.com). The Galaxy team can walk you through the process.
## What's Next?
---
# MongoDB Oplog Setup (https://help.galaxycloud.app/docs/databases/mongodb-oplog-setup)
Want faster, more efficient real-time updates in your Meteor app? Oplog tailing is the answer. Instead of polling your database for changes, your app listens directly to MongoDB's operations log. The result? Instant reactivity with less database load.
## What is the Oplog?
The oplog (operations log) is a special capped collection in MongoDB that records every write operation. It's how replica sets stay in sync, but it's also incredibly useful for applications that need to react to data changes in real-time.
For Meteor apps, oplog tailing supercharges reactivity. Your `observeChanges` callbacks fire instantly when data changes, rather than relying on polling. This means snappier UIs and happier users.
Oplog tailing requires a MongoDB replica set. Standalone MongoDB instances don't have an oplog. Galaxy Database clusters and most production MongoDB services (like MongoDB Atlas) run as replica sets by default.
## Why Set Up Oplog Tailing?
There are a few good reasons to enable oplog tailing:
* **Better Meteor reactivity**: Your app sees database changes instantly. No more waiting for the next poll interval.
* **Reduced database load**: Polling means constant queries asking "did anything change?" Oplog tailing eliminates that overhead.
* **Monti APM insights**: With oplog configured, Monti APM can show you detailed metrics around `observeChanges` and oplog notifications. Without it, those graphs stay empty.
* **Third-party integrations**: Many tools that sync with MongoDB rely on oplog tailing to detect changes in real-time.
***
## Creating an Oplog User
Your oplog user needs read access to the `local` database (where the oplog lives). Here's how to set it up.
### Connect to Your Database
Use MongoDB Shell, MongoDB Compass, or any MongoDB client to connect to your database with admin credentials.
```bash
mongosh "mongodb://admin:password@your-host:27017/admin"
```
### Create the Oplog User
Switch to the `admin` database and create a user with read access to the `local` database:
```javascript
use admin;
db.createUser({
user: "oploguser",
pwd: "YourSecurePassword",
roles: [{ role: "read", db: "local" }]
});
```
The `read` role on the `local` database is all your oplog user needs. Keep it minimal for security.
### Verify the User
Test that your new user can authenticate:
```bash
mongosh "mongodb://oploguser:YourSecurePassword@your-host:27017/local?authSource=admin"
```
If you can connect without errors, you're good to go.
Use a strong, unique password for your oplog user. This credential will be stored in your app's environment variables. Treat it like any other database credential.
***
## Building the Oplog Connection String
The oplog connection string looks similar to your main `MONGO_URL`, but it points to the `local` database where the oplog resides.
Here's the format:
```
mongodb://oploguser:password@host1:27017,host2:27017,host3:27017/local?authSource=admin&replicaSet=yourReplicaSetName
```
Let's break that down:
| Part | Description |
| ------------------------------- | ----------------------------------------------------- |
| `oploguser:password` | The credentials you just created |
| `host1:27017,host2:27017,...` | Your replica set hosts (same as your main connection) |
| `/local` | The database containing the oplog (always `local`) |
| `authSource=admin` | Where your oplog user was created |
| `replicaSet=yourReplicaSetName` | Your replica set name |
Find your replica set name and hosts in your MongoDB connection string. For Galaxy Database, check the Overview tab of your cluster details page.
***
## Configuring Your Meteor App
Add the `MONGO_OPLOG_URL` environment variable to your Meteor settings. Place it in the `galaxy.meteor.com.env` section, right below your `MONGO_URL`:
```json
{
"galaxy.meteor.com": {
"env": {
"ROOT_URL": "https://myapp.us.galaxycloud.app",
"MONGO_URL": "mongodb+srv://user:password@cluster.mongodb.net/yourdb",
"MONGO_OPLOG_URL": "mongodb://oploguser:password@cluster.mongodb.net/local?authSource=admin&replicaSet=rs0"
}
}
}
```
Notice the parameters at the end of `MONGO_OPLOG_URL`. Each one serves a specific purpose:
| Parameter | Why It's Needed |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `/local` | The oplog lives in MongoDB's `local` database, not your application database. This tells Meteor where to find the oplog collection. |
| `authSource=admin` | Your oplog user was created in the `admin` database. This parameter tells MongoDB where to look up the credentials for authentication. Without it, MongoDB tries to authenticate against `local` and fails. |
| `replicaSet=rs0` | Identifies which replica set to connect to. Required for oplog tailing since the oplog only exists on replica sets. Replace `rs0` with your actual replica set name. |
Save your settings and deploy. Meteor automatically detects `MONGO_OPLOG_URL` and enables oplog tailing.
Use `MONGO_OPLOG_URL` for modern Meteor versions. You might see references to `METEOR_OPLOG_URL` in older documentation, but that's legacy. Stick with `MONGO_OPLOG_URL`.
***
## Verifying Oplog Tailing
How do you know it's working? A few ways:
* **Check your app logs**: When Meteor starts with oplog tailing enabled, you'll see messages about connecting to the oplog.
* **Test reactivity**: Open your app in two browser windows. Make a change in one. If oplog tailing is working, the other window updates almost instantly.
* **Monti APM**: If you're on Galaxy's Professional plan, check the Monti APM dashboard. The `observeChanges` and Oplog graphs should now show data. If these were empty before, that's your confirmation.
***
## Common Issues
Double-check your credentials and make sure `authSource=admin` is in your connection string. The oplog user was created in the `admin` database, so MongoDB needs to know where to look.
Oplog tailing only works with replica sets. If you're running a standalone MongoDB instance, you'll need to convert it to a replica set first. Most production MongoDB services already run as replica sets.
After adding `MONGO_OPLOG_URL`, redeploy your app. Give it a few minutes to collect data. If graphs are still empty, verify your oplog URL is correct and the user has read access to the `local` database.
Make sure you're pointing to `/local` (not your app's database). The oplog lives in the `local` database regardless of which database your app uses.
The same principles apply. Create a user with read access to `local`, build the connection string pointing to `/local`, and add it as `MONGO_OPLOG_URL`. Atlas and similar services support oplog tailing on all their replica set deployments.
***
## Quick Reference
Here's everything in one place:
**Create the user:**
```javascript
use admin;
db.createUser({
user: "oploguser",
pwd: "YourSecurePassword",
roles: [{ role: "read", db: "local" }]
});
```
**Connection string format:**
```
mongodb://oploguser:password@hosts/local?authSource=admin&replicaSet=rsName
```
**Meteor settings:**
```json
{
"galaxy.meteor.com": {
"env": {
"MONGO_URL": "your-main-connection-string",
"MONGO_OPLOG_URL": "your-oplog-connection-string"
}
}
}
```
That's it. Deploy, and your Meteor app will use oplog tailing for lightning-fast reactivity.
***
## What's Next?
---
# MongoDB SSL Certificate Setup (Meteor) (https://help.galaxycloud.app/docs/databases/mongodb-ssl-meteor)
SSL encrypts the connection between your Meteor app and MongoDB, protecting your data in transit. If you're using Galaxy Database, setting this up takes just a few minutes.
**Time Required**: About 5 minutes
**What you'll need**: A Meteor project, a Galaxy Database MongoDB instance, and your `settings.json` file
**Using Node.js instead?** Check the [Node.js SSL setup guide](/docs/databases/mongodb-ssl-nodejs). Node.js handles certificates differently.
***
## Setting Up SSL
### Download the SSL Certificate
Open the Galaxy dashboard and navigate to your MongoDB cluster's **Overview** page. You'll find a download link for the SSL certificate there.
Download the certificate file. You'll add it to your Meteor project in the next step.
### Add the Certificate to Your Project
Create a `private` folder in the root of your Meteor project (if you don't already have one). Drop the downloaded certificate file inside it.
For this guide, we'll assume the file is named `certificate.pem`. Your project structure should look like this:
```
your-meteor-app/
├── private/
│ ├── certificate.pem
│ └── settings.json (recommended location)
├── client/
├── server/
└── ...
```
Storing your `settings.json` in the `private` folder alongside your certificate keeps your configuration organized and out of the client bundle.
### Configure Your Settings
Open (or create) your `settings.json` file and add the SSL configuration along with your MongoDB connection string:
```json
{
"packages": {
"mongo": {
"options": {
"tls": true,
"tlsCAFileAsset": "certificate.pem"
}
}
},
"galaxy.meteor.com": {
"env": {
"MONGO_URL": "mongodb://user:password@host1:27017,host2:27017,host3:27017/yourdb?replicaSet=yourReplicaSet&ssl=true&authSource=admin"
}
}
}
```
Two key settings here:
**`tlsCAFileAsset`**: Tells Meteor to look for the SSL certificate inside the `private` folder. You only need the filename, not the full path.
**`MONGO_URL`**: Your MongoDB connection string. Make sure it includes `ssl=true` and `authSource=admin` as query parameters. You'll find the full connection string on your Galaxy Database cluster's **Credentials** section.
### Deploy Your App
Deploy with the `--settings` flag pointing to your settings file:
```bash
meteor deploy myapp --settings private/settings.json
```
That's it. Meteor reads the certificate from `private/`, establishes the SSL connection, and your data travels encrypted between your app and MongoDB.
***
## Push to Deploy Configuration
If you're using [Push to Deploy](/docs/apps/meteor/push-to-deploy) instead of the CLI, you'll need to tell Galaxy where your settings file lives.
During the Push to Deploy setup (or in your app's **Settings** page), look for the **Settings File Path** field. Enter the relative path to your settings file:
```
private/settings.json
```
Galaxy reads this file from your repository on every deployment. Your SSL certificate (inside the `private` folder) gets bundled automatically since Meteor includes everything in `private/` in the app bundle.
If your `settings.json` contains secrets (API keys, database passwords), consider using the **Meteor Settings JSON** field in the Galaxy dashboard instead of committing secrets to your repository. You can split your configuration: keep non-sensitive settings in the file and paste sensitive values directly in the dashboard.
***
## Connection String Parameters
Your `MONGO_URL` needs specific parameters for SSL to work correctly. Here's what each one does:
| Parameter | Purpose |
| --------------------------- | ------------------------------------------------------------------- |
| `ssl=true` | Enables SSL/TLS encryption for the connection |
| `authSource=admin` | Tells MongoDB to authenticate against the `admin` database |
| `replicaSet=yourReplicaSet` | Identifies your replica set (required for Galaxy Database clusters) |
If you're missing `authSource=admin`, MongoDB tries to authenticate against your app's database and fails. Always include it when connecting to Galaxy Database.
***
## Common Questions
The `tls: true` option enables TLS/SSL encryption on the connection. The `tlsCAFileAsset` option tells Meteor which certificate file to use for verifying the server's identity. You need both for a fully secure connection to Galaxy Database.
The `tlsAllowInvalidCertificates: true` option skips certificate validation entirely. This is used for Galaxy's free MongoDB tier (where certificates aren't installed on every machine), but for dedicated Galaxy Database clusters, using the proper SSL certificate with `tlsCAFileAsset` is the recommended approach.
In the Galaxy dashboard, click on your MongoDB cluster and look in the **Credentials** section. You'll see the full connection string there. Copy it and add the required parameters (`ssl=true`, `authSource=admin`) if they're not already included.
Yes. Adding or changing the SSL certificate requires a new deployment since Meteor bundles the `private` folder at build time. Redeploying your app picks up the new certificate automatically.
Double-check that the certificate file is inside the `private` folder (not a subfolder), the filename in `tlsCAFileAsset` matches exactly (including the extension), and the certificate hasn't expired. You can re-download the certificate from the Galaxy Database overview page if needed.
***
If you're having trouble with SSL setup, [reach out to Galaxy support](/docs/getting-started/support). We can verify your certificate configuration and help troubleshoot connection issues.
## What's Next?
---
# MongoDB SSL Certificate Setup (Node.js) (https://help.galaxycloud.app/docs/databases/mongodb-ssl-nodejs)
SSL encrypts the connection between your Node.js app and MongoDB, keeping your data safe in transit. If you're using Galaxy Database, the whole setup takes just a few minutes.
**Time Required**: About 5 minutes
**What you'll need**: A Node.js project, a Galaxy Database MongoDB instance, and your SSL certificate file
**Using Meteor?** Check the [Meteor SSL setup guide](/docs/databases/mongodb-ssl-meteor) instead. Meteor handles certificates differently.
***
## Setting Up SSL
### Download the SSL Certificate
Open the Galaxy dashboard and navigate to your MongoDB cluster's **Overview** page. You'll find a download link for the SSL certificate there.
Download the certificate file (usually a `.crt` or `.pem` file). You'll reference this file in your app's connection code.
### Add the Certificate to Your Project
Create a `certs` directory in your project root and place the certificate file inside it. This is for local development only:
```
your-node-app/
├── certs/
│ └── galaxy-mongodb.crt
├── src/
├── package.json
└── .gitignore
```
If your repository is public, never commit certificate files. Add `certs/` to your `.gitignore` and use an environment variable for production (covered in the Deploying to Galaxy section below). For private repos, committing the certificate is fine.
### Install the MongoDB Driver
If you haven't already, install the MongoDB driver for Node.js:
```bash
npm install mongodb
```
```bash
npm install mongoose
```
This guide covers both options. Pick whichever one your project uses.
### Configure the SSL Connection
Point your MongoDB connection to the certificate file. Here's how it works with each driver:
```javascript
const { MongoClient } = require('mongodb');
const path = require('path');
const certPath = path.resolve('certs/galaxy-mongodb.crt');
const client = new MongoClient(process.env.MONGO_URL, {
tls: true,
tlsCAFile: certPath,
authSource: 'admin',
connectTimeoutMS: 10000,
serverSelectionTimeoutMS: 5000,
});
await client.connect();
console.log('Connected to MongoDB with SSL');
```
```javascript
const mongoose = require('mongoose');
const path = require('path');
const certPath = path.resolve('certs/galaxy-mongodb.crt');
await mongoose.connect(process.env.MONGO_URL, {
tls: true,
tlsCAFile: certPath,
authSource: 'admin',
connectTimeoutMS: 10000,
serverSelectionTimeoutMS: 5000,
});
console.log('Connected to MongoDB with SSL');
```
### Set Your Connection String
Add `MONGO_URL` as an environment variable in the Galaxy dashboard (under your app's **Variables** section). The connection string should include `ssl=true` and `authSource=admin`:
```
mongodb://user:password@host1:27017,host2:27017,host3:27017/yourdb?replicaSet=yourReplicaSet&ssl=true&authSource=admin
```
You'll find the full connection string on your Galaxy Database cluster's **Credentials** section.
***
## Connection String Parameters
Your `MONGO_URL` needs specific parameters for SSL to work correctly:
| Parameter | Purpose |
| --------------------------- | ------------------------------------------------------------------- |
| `ssl=true` | Enables SSL/TLS encryption for the connection |
| `authSource=admin` | Tells MongoDB to authenticate against the `admin` database |
| `replicaSet=yourReplicaSet` | Identifies your replica set (required for Galaxy Database clusters) |
If you're missing `authSource=admin`, MongoDB tries to authenticate against your app's database and fails. Always include it when connecting to Galaxy Database.
***
## TLS Options Reference
Here's a quick reference for the TLS options you can pass to the driver:
| Option | Type | Description |
| ----------------------------- | --------- | ------------------------------------------------------------- |
| `tls` | `boolean` | Enables TLS/SSL encryption |
| `tlsCAFile` | `string` | Path to the certificate authority file |
| `tlsAllowInvalidCertificates` | `boolean` | Skips certificate validation (not recommended for production) |
| `connectTimeoutMS` | `number` | How long to wait for a connection before timing out |
| `serverSelectionTimeoutMS` | `number` | How long to wait for a server to be selected |
The default `serverSelectionTimeoutMS` is 30 seconds, which can make debugging slow. Setting it to 5000 (5 seconds) gives you faster feedback when something is misconfigured.
***
## Deploying to Galaxy
Your certificate file needs to be accessible at runtime. You have two options depending on how you manage secrets.
If your repository is private, you can include the certificate file directly in your project (in the `certs/` directory). Your app reads it from the filesystem at runtime, just like it does locally. This is the simplest approach.
Only commit certificate files to private repositories. If your repo is public (or might become public), use the environment variable method instead.
Prefer to keep the certificate out of version control entirely? Store the certificate content as an environment variable and write it to disk at startup:
```javascript
const fs = require('fs');
const path = require('path');
const certPath = path.resolve('/tmp/galaxy-mongodb.crt');
if (process.env.MONGO_SSL_CERT && !fs.existsSync(certPath)) {
fs.writeFileSync(certPath, process.env.MONGO_SSL_CERT);
}
// Then use certPath as your tlsCAFile
```
In the Galaxy dashboard, go to your app's **Variables** section and add `MONGO_SSL_CERT` as an environment variable. Paste the full certificate content as the value.
This is the more secure option, especially for teams with open-source repos or strict security policies.
***
## Common Questions
Having `ssl=true` in the connection string is enough to enable encryption. Adding `tls: true` in the options object is redundant but harmless. The important part is `tlsCAFile`, which tells the driver where to find the certificate for server verification.
Setting `tlsAllowInvalidCertificates: true` skips certificate validation entirely. This works for Galaxy's free MongoDB tier (where certificates aren't installed on every machine), but for dedicated Galaxy Database clusters, using the proper certificate with `tlsCAFile` is the recommended and more secure approach.
Start with the basics: verify your `MONGO_URL` is correct (especially the host, port, and credentials), confirm your database is running in the Galaxy dashboard, and make sure the certificate file path resolves correctly. If you're connecting from outside Galaxy, check that network access isn't restricted.
Yes. Most Node.js MongoDB libraries use the official driver under the hood, so the same TLS options apply. Check your library's documentation for how to pass driver-level connection options. Some libraries accept TLS settings directly in the connection string, while others require them in a configuration object.
In the Galaxy dashboard, click on your MongoDB cluster and look in the **Credentials** section. You'll see the full connection string there. Copy it and make sure it includes `ssl=true` and `authSource=admin`.
***
If you're having trouble with SSL setup, [reach out to Galaxy support](/docs/getting-started/support). We can verify your certificate configuration and help troubleshoot connection issues.
## What's Next?
---
# MongoDB (https://help.galaxycloud.app/docs/databases/mongodb)
# MongoDB on Galaxy
Create and manage MongoDB databases on Galaxy with automatic backups and zero transfer fees.
Galaxy offers a free MongoDB tier perfect for development and learning. Free databases have usage limits to ensure fair access for everyone. Learn about storage limits and when to upgrade in our [Fair Usage Policy for Free MongoDB](/docs/databases/free-mongodb-fair-usage).
***
## Create a MongoDB Database
Getting a MongoDB database running takes about two minutes.
### Open Your Dashboard
Go to your [Galaxy dashboard](https://my.galaxycloud.app) and click **Databases** in the sidebar.
### Start Database Creation
Click **Create Database** and select **MongoDB** as your database type.
### Configure Your Instance
Choose your MongoDB version and instance size. Pick the region closest to your app for best performance.
### Create and Wait
Click **Create Database & Start Billing**. Galaxy provisions your database in a few minutes. You'll see "Running" when it's ready.
Deploy your database in the same region as your app. This minimizes latency and keeps your data transfer free.
***
## Connect to Your App
Click your database in the dashboard to see the connection string. Copy it and add it as an environment variable in your app's settings.
The exact variable name depends on your framework:
* **Meteor apps**: Use `MONGO_URL`
* **Node.js apps**: Typically `MONGODB_URL` or `DATABASE_URL`
* **Other frameworks**: Check your framework's documentation for the expected variable name
Never hardcode your connection string in your code. Always use environment variables so it stays secure and out of version control.
***
## Features
**Automatic Backups**: Daily backups included with all plans. Your data is protected without you lifting a finger.
**Replica Sets Available**: High availability option for production apps. Your data is replicated across multiple nodes, so if one goes down, others keep running.
**Zero Transfer Fees**: Data moving between your Galaxy app and database is free. No surprise charges on your bill.
***
## Common Questions
Galaxy creates automatic daily backups of your MongoDB database. You can also create manual backups anytime from your database's settings page. Backups are retained for 4 days by default, with extended retention available if you need it.
Pricing depends on your instance size and whether you choose standalone or replica set. See the [Billing section](/docs/billing/database) for the complete pricing breakdown.
Galaxy's free MongoDB tier includes up to 256MB of storage and is perfect for learning and development. Free databases don't have uptime guarantees like paid tiers. For complete details on free tier limits, usage guidelines, and when to upgrade, check our [Fair Usage Policy for Free MongoDB](/docs/databases/free-mongodb-fair-usage).
Everything happens in your [Galaxy dashboard](/docs/dashboard/databases). View metrics, check backups, adjust settings, and monitor performance all from one place.
Yes. Use the connection string from your dashboard to connect any MongoDB-compatible tool. Check out our [TablePlus guide](/docs/databases/connect) for step-by-step instructions on connecting external database managers.
The **Databases** tab only lists free databases that were linked to an app at deployment time on the current Galaxy infrastructure. If your free database was provisioned before this feature was introduced, it won't appear there. It's still active and reachable via the `MONGO_URL` in your app's environment settings. To get full dashboard visibility going forward, redeploy your app with the **Add Free MongoDB** toggle enabled, or migrate to a [paid MongoDB instance](/docs/billing/database).
***
## What's Next?
---
# PostgreSQL (https://help.galaxycloud.app/docs/databases/postgresql)
# PostgreSQL on Galaxy
Galaxy gives you a fully managed PostgreSQL database, provisioned in minutes and connected to your app with a single environment variable.
***
## Create a PostgreSQL Database
### Open Your Dashboard
Go to your [Galaxy dashboard](https://my.galaxycloud.app) and click **Databases** in the sidebar.
### Start Database Creation
Click **Create Database** and select **PostgreSQL** as your database type.
### Configure Your Instance
Choose your PostgreSQL version and instance size. Pick the region closest to your app for best performance.
### Create and Wait
Click **Create Database & Start Billing**. Galaxy provisions your database in a few minutes. You'll see "Running" when it's ready.
Deploy your database in the same region as your app. This minimizes latency and keeps your data transfer free.
***
## Connect to Your App
Click your database in the dashboard to see the connection string. Copy it and add it as an environment variable in your app's settings.
The exact variable name depends on your framework:
* **Node.js apps**: Often `DATABASE_URL`, `DB_HOST`, or separate `DB_USER`, `DB_PASSWORD`, `DB_DATABASE` variables
* **Python apps**: Typically `DATABASE_URL`
* **AdonisJS apps**: Usually `DB_CONNECTION`, `DB_HOST`, `DB_USER`, `DB_PASSWORD`, `DB_DATABASE`
Never hardcode your connection string in your code. Always use environment variables so it stays out of version control.
***
## Security
Your database is protected with username and password authentication. All connections from your Galaxy apps stay within Galaxy's private network and never traverse the public internet.
***
## Features
**Automatic Backups**: Daily backups included with all plans. Your data is protected without any extra configuration.
**Zero Transfer Fees**: Data moving between your app and database is free. No surprise charges for internal traffic.
***
## Common Questions
Galaxy creates automatic daily backups of your PostgreSQL database. You can also create manual backups anytime from your database's settings page. Backups are retained for 4 days by default, with extended retention available if you need it.
Pricing depends on your instance size. See the [Billing section](/docs/billing/database) for the complete pricing breakdown.
Everything happens in your [Galaxy dashboard](/docs/dashboard/databases). View metrics, check backups, adjust settings, and monitor performance all from one place.
Yes. Use the connection string from your dashboard to connect any PostgreSQL-compatible tool like TablePlus, pgAdmin, or DBeaver. Check out our [TablePlus guide](/docs/databases/connect) for step-by-step instructions.
***
## What's Next?
---
# Redis (https://help.galaxycloud.app/docs/databases/redis)
# Redis on Galaxy
Galaxy hosts and manages Redis for you. Spin up an instance in minutes and connect it to any app on the platform.
***
## Create a Redis Database
### Open Your Dashboard
Go to your [Galaxy dashboard](https://my.galaxycloud.app) and click **Databases** in the sidebar.
### Start Database Creation
Click **Create Database** and select **Redis** as your database type.
### Configure Your Instance
Choose your instance size and the region closest to your app.
### Create and Wait
Click **Create Database & Start Billing**. Galaxy provisions your instance in a few minutes. You'll see "Running" when it's ready.
***
## Connect to Your App
Click your Redis instance in the dashboard to see the connection string. Copy it and add it as an environment variable in your app's settings.
The exact variable name depends on your framework:
* **Node.js apps**: Often `REDIS_URL` or `REDIS_HOST`
* **Python apps**: Typically `REDIS_URL`
* **Other frameworks**: Check your framework's documentation for the expected variable name
Never hardcode your connection string in your code. Always use environment variables so it stays secure and out of version control.
***
## Features
**Automatic Backups**: Daily backups are included with every Redis instance on Galaxy.
**Zero Transfer Fees**: Data moving between your Galaxy app and your Redis instance is free.
**Flexible Instance Sizing**: Pick the memory size that fits your workload. Upgrade any time from the dashboard.
***
## Common Questions
Pricing depends on your instance size. See the [Billing section](/docs/billing/database) for the complete pricing breakdown.
Everything happens in your [Galaxy dashboard](/docs/dashboard/databases). View metrics, check connection status, and monitor memory usage from one place.
When Redis hits its memory limit, it starts evicting old data based on its eviction policy. If you're constantly hitting memory limits, consider upgrading to a larger instance from the dashboard.
***
## What's Next?
---
# AI Integration (https://help.galaxycloud.app/docs/getting-started/ai-integration)
Galaxy documentation is optimized for AI tools. Every page is available as clean markdown by appending `.md` to its URL. Two dedicated endpoints serve the full documentation in plain text for LLMs and AI agents, and a **Copy as Markdown** button is included on every page.
***
## llms.txt
The `/llms.txt` endpoint returns a lightweight index of every documentation page with links.
```
https://help.galaxycloud.app/llms.txt
```
This is the recommended starting point for AI agents. It provides a list of all available pages so the agent can decide which ones to fetch. The format follows the [llms.txt standard](https://llmstxt.org/).
***
## Per-Page Markdown
Append `.md` to any documentation page URL to get its content as clean, plain-text markdown.
```
https://help.galaxycloud.app/docs/getting-started/quickstart.md
```
This is useful when an AI agent only needs a specific page rather than the full documentation. The response is `text/plain` with a 1-hour cache.
***
## llms-full.txt
The `/llms-full.txt` endpoint returns the full content of every documentation page, cleaned and concatenated into a single plain text file.
```
https://help.galaxycloud.app/llms-full.txt
```
Use this endpoint when you want to load the entire documentation into a single prompt. The output strips all custom components and import statements, leaving clean markdown.
***
## Copy as Markdown
Every documentation page has a **Copy as Markdown** button below the page description. Click it to copy the current page's content as clean markdown, ready to paste into any AI assistant.
The copied content has all custom components and formatting removed, so it reads as plain markdown that any LLM can process.
***
## Common Questions
Import statements and custom MDX components (Callout, Steps, Tabs, Cards, Accordions, TechLogo, Video, ImageZoom) are removed. The result is clean markdown with headings, paragraphs, lists, code blocks, and links preserved.
Yes. Both `/llms.txt` and `/llms-full.txt` return `text/plain` responses with a 1-hour cache. You can fetch them from scripts, CI pipelines, or any HTTP client.
The endpoints serve content from the latest deployment. When documentation is updated and deployed, the endpoints reflect the changes immediately. Responses are cached for 1 hour.
***
## What's Next?
---
# Creating a Galaxy Account (https://help.galaxycloud.app/docs/getting-started/creating-account)
***
## Let's Get Started
Creating a Galaxy account takes just a few minutes. Pick your preferred signup method below and you'll be ready to deploy your first app in no time.
If you sign up with Google or GitHub, Galaxy creates a username for you automatically. You can't customize it later, so keep that in mind when choosing your auth method.
### Visit the signup page
Head to [https://my.galaxycloud.app/signup](https://my.galaxycloud.app/signup).
### Choose your username
Pick something memorable, you'll use it to access your Galaxy dashboard.
### Enter your email
Use an email you have access to. Galaxy sends confirmation messages and account updates here.
### Create a strong password
Use at least 8 characters with at least one number and one uppercase letter.
### Confirm your password
Double-check for typos (happens to everyone).
### Add a coupon code (optional)
Have a promo code? Paste it in and click Apply. No code? Skip this step.
### Click Sign up
Hit the Sign up button, confirm your email, and you're done!
### Select "Sign up with Google"
On the signup page, click this option.
### Authorize the connection
Follow Google's prompts and you'll be back at Galaxy in seconds.
### You're in
Galaxy creates a username automatically. It's ready to use right away.
### Set a Galaxy password later (optional)
Want a Galaxy-specific password? You can create one anytime in your account settings.
### Select "Sign up with GitHub"
On the signup page, click this option.
### Authorize the connection
Follow GitHub's prompts and you'll be back at Galaxy in seconds.
### You're in
Galaxy creates a username automatically. It's ready to use right away.
### Set a Galaxy password later (optional)
Want a Galaxy-specific password? You can create one anytime in your account settings.
***
## Your Galaxy Dashboard Awaits
Once you've signed up and confirmed your email, you'll land in your dashboard. Here's what you can start doing right away.
Start with the Free plan. It's perfect for staging and testing, then scale up whenever you need it. We've designed Galaxy to make it simple to start building right away, so don't worry about a steep learning curve.
[Galaxy's support team](/docs/getting-started/support) knows the full stack and can help with pretty much any question. They're friendly and respond fast.
***
## What's Next?
---
# Introduction to Galaxy (https://help.galaxycloud.app/docs/getting-started)
# Welcome to Galaxy
Galaxy (previously known as Meteor Cloud) is a cloud platform that handles everything: hosting your apps, managing databases, monitoring performance, all from one unified dashboard. No more switching between services. No more complexity. Just deploy, scale, and build.
Apps and databases in one place. Everything you need to ship confidently.
***
## Why Developers Choose Galaxy
Stop managing infrastructure. Start building what matters. Here's what you get:
Host **Meteor**, **Node.js**, **Python**, and **AdonisJS** apps with enterprise features: triggers, notifications, IP whitelisting, and app protection built in.
Invite collaborators, manage permissions, and scale your team within the Galaxy dashboard. Real collaboration, built in.
Start instantly with our Free plan, complete with MongoDB auto-configuration. Perfect for staging, testing, and getting your idea live.
Provision MongoDB, PostgreSQL, or Redis alongside your apps. Automatic backups, zero data transfer fees, and simple scaling.
Get production-grade APM with Monti for your Meteor apps. Identify bottlenecks, track metrics, and optimize performance in real-time. Included with Professional plans.
Real engineers who understand application architecture. You're never troubleshooting alone.
***
## What Can You Do With Galaxy?
### Deploy and Scale Meteor Apps
Galaxy is the premier hosting platform for Meteor applications. It's built by the Meteor team, so you get everything designed specifically for how Meteor works.
**Deploy with confidence:**
* **Push to Deploy**: Update your app straight from Git. No manual steps.
* **Meteor CLI**: Deploy your app directly from the command line with the Meteor CLI.
* **Version Management & Easy Rollbacks**: Every deploy creates a version snapshot. If something breaks, roll back to a previous version with one click. No stress, no downtime nightmares.
* **Auto-Scaling**: Customize container size and count. Let Galaxy scale automatically as your app grows.
* **Real-Time Monitoring**: Integrated Monti APM helps you optimize performance (Professional Plan).
* **Seamless Database Setup**: MongoDB integration built for Meteor, ready in seconds.
* **Deep Expertise**: The engineers who built Meteor support your deployments.
Galaxy is created and maintained by the people behind Meteor. You get hosting optimized for your framework.
### Host Node.js, Python, and AdonisJS Apps
Beyond Meteor, Galaxy supports any Node.js, Python, or AdonisJS application with the same simple deployment experience and enterprise-grade features.
**Deploy with the same ease:**
* **Push to Deploy**: Update directly from Git. Works with any supported language.
* **Galaxy CLI**: Deploy and manage web apps from the command line with the Galaxy CLI.
* **Version Management & One-Click Rollbacks**: Every deployment is versioned. Made a mistake? Revert to a previous version instantly without fussing around with git commands or complicated rollback procedures.
* **Simple Scaling**: Adjust container size and count based on your needs.
* **Unified Dashboard**: Manage all your apps in one place. Monitor usage, adjust settings, control everything from one interface.
* **Expert Support**: Real engineers supporting your stack.
Deploy frequently without fear. If a deployment goes sideways, roll back instantly and get back to building.
### Manage Databases Alongside Your Apps
Host MongoDB, PostgreSQL, or Redis databases right next to your applications. Simple provisioning, automatic backups, and zero hassle.
**Database hosting done right:**
* **Quick Setup**: Provision a database in seconds without leaving Galaxy.
* **Automatic Daily Backups**: Your data is protected automatically.
* **Zero Data Transfer Fees**: Connect your apps to your databases with no hidden charges. Internal traffic is free.
* **Easy Scaling**: Resize your database as your needs change.
* **Enterprise Security**: Industry-standard encryption and security for your data.
* **Single Dashboard**: Manage apps and databases together. One place for everything.
Stop managing multiple database providers. Host MongoDB, PostgreSQL, and Redis right where your apps live.
### Monitor Performance in Real Time
**Monti APM** gives you production-grade application performance monitoring built specifically for Meteor. It's included with the Professional Plan.
Identify bottlenecks, see exactly where time is spent, and make data-driven optimization decisions, all from within Galaxy.
**Ready to learn more?** [Get started with APM](/docs/apps/meteor/monti-apm).
Monitor your production apps in real time with APM included on Professional plans.
***
## Ready to Ship Your App?
You don't need to know everything upfront. Galaxy is built to get you running fast. Create your account and deploy your first app today. Everything else is just a docs search away.
Want to jump into a specific feature? Head over to our [full documentation](/docs) to explore what you're looking for.
---
# Looking for the legacy docs? (https://help.galaxycloud.app/docs/getting-started/looking-for-the-legacy-docs)
These docs cover **Galaxy Metal**, the current generation of Galaxy's cloud hosting platform, along with **Web Apps**. If you're here, this is almost certainly where you want to be. Galaxy's in-app menus link here, and this is where all new documentation is published.
***
## Galaxy Legacy docs
If your app runs on **Galaxy Legacy**, you'll want the legacy docs instead:
**[help-legacy.galaxycloud.app](https://help-legacy.galaxycloud.app/en/)**
Not sure which platform your app is on? Check your app in the Galaxy dashboard. Apps on Galaxy Metal and Web Apps use these docs. Apps on Galaxy Legacy use the legacy docs.
We maintain both sets of docs and will continue to do so for as long as apps run on Galaxy Legacy.
***
## What's Next?
---
# Quickstart Guide (https://help.galaxycloud.app/docs/getting-started/quickstart)
Whether you're running Meteor, Node.js, Python, or AdonisJS, you'll be deployed in about 5 minutes.
**Time Required**: About 5 minutes
**What you'll need**: A repository with your app code on a supported Git provider and a Galaxy account
To deploy any application on Galaxy, you must add a valid payment method for identity verification. We'll place a small temporary hold on your card to verify it, then automatically refund it. You'll only be charged if you deploy a paid app.
***
## The Quick Path
### Create Your Galaxy Account
Head to [https://my.galaxycloud.app/signup](https://my.galaxycloud.app/signup) and sign up. Verify your email and you're good to go.
### Choose Your App Type
Log in to your [Galaxy dashboard](https://my.galaxycloud.app/) and click **Create New** in the top right. A wizard opens asking what you're deploying.
Pick **Meteor.js** for your Meteor application. Galaxy automatically detects your Meteor version (1, 2, or 3) from your project.
Pick **Node.js** for Express, Next.js, or any Node.js framework. You'll select the specific version later in configuration.
Pick **Python** for Flask, Django, or other Python frameworks. You'll select the specific version later in configuration.
Pick **AdonisJS** for AdonisJS 6 or AdonisJS 7 applications. This comes with pre-configured settings optimized for the framework.
Click your choice and move on.
### Connect Your Repository
Choose your Git provider (**Continue with GitHub** or **Continue with Bitbucket**) and authorize Galaxy to access your repositories. This one-time setup lets Galaxy watch your repo for changes and deploy automatically.
### Select Your Repository
Browse your repositories or use the filter to find the one with your app. Click **Import** next to it.
Don't see your repository? Check that Galaxy has permission to access it in your Git provider's settings.
### Select Account and Plan
Pick your Galaxy account (Personal Account or an Organization), then choose a plan.
* **Free**: Testing and learning (one Tiny container)
* **Essentials**: Production apps with flexible sizes
* **Professional**: Full features plus Monti APM
* **Sandbox**: Testing and learning (one Nano container)
* **Production**: Live apps with multiple sizes
* **Business** (coming soon): Enterprise options
Select a container size from the table shown. Don't overthink it. Start smaller and scale up later if needed. Click **Next Step** when ready.
### Configure and Deploy
Fill in the essential fields:
* **App Display Name**: A friendly name for your dashboard
* **Custom Subdomain**: Your app's URL (pick something memorable)
* **Branch**: Which Git branch to watch (usually `main` or `master`)
* **Region**: Pick the one closest to your users (paid plans only; free apps deploy to us-east-1)
* **Docker Preset**: Pre-configured runtime for your app
* **Health Check Path**: HTTP path Galaxy pings to verify your app is running
Add any environment variables your app needs (API keys, database URLs, etc.), then click **Deploy**.
Never hardcode secrets in your code. Always use environment variables.
Galaxy clones your repo, installs dependencies, builds your app, and goes live. Your app URL appears when it's done. That's it!
***
## Deploy Using the CLI
Want to deploy from your terminal? Galaxy also supports CLI deployments for Meteor and other runtimes. This gives you more control over the deployment process and works great for automation and CI/CD pipelines.
Check out the [Galaxy CLI](/docs/apps/webapps/galaxy-cli) and the [Meteor CLI](/docs/apps/meteor/cli) guides to get started from the command line.
***
## After Deployment
Your app is now live. Galaxy handles the infrastructure automatically:
* **SSL certificates**: HTTPS works out of the box
* **Health monitoring**: Galaxy watches your app and restarts if needed
* **Zero-downtime updates**: Push code, Galaxy deploys automatically
* **Automatic restarts**: If your app crashes, Galaxy brings it back
***
## Common Questions
Galaxy supports GitHub and Bitbucket for Push to Deploy. If your code is on another provider, push it to one of those first.
**App Type** is what you select at the start: Meteor.js, AdonisJS, Node.js, or Python. This determines your runtime environment.
**Docker Preset** appears later for Node.js and Python apps only. It lets you pick a specific version (like Node.js 20 LTS or Python 3.12). Meteor.js and AdonisJS apps don't need Docker Preset selection since their environments are pre-configured.
Yes.
Your first deploy usually takes a few minutes. Subsequent deploys are often faster since Galaxy caches some build steps.
No. Use a paid plan for live apps. Free and Sandbox are great for testing, but they're not designed for production traffic.
Of course! Upgrade or downgrade anytime from your app's [Plans](/docs/dashboard/apps/plans) section. No downtime required.
***
## Troubleshooting
Having trouble with your deployment? Here are common issues and how to solve them.
Check the [Logs](/docs/dashboard/apps/logs) section of your app's dashboard. The logs show exactly what went wrong. Common causes include:
* Missing dependencies (check your `package.json`, `requirements.txt`, or build configuration)
* Incorrect build commands (make sure your build script is configured correctly)
* Environment variable issues (ensure required variables are set in your app configuration)
Make sure your app listens on the `PORT` environment variable that Galaxy provides. Don't hardcode ports like 3000 or 5000. Galaxy automatically sets the `PORT` variable, and your app needs to use it.
Galaxy needs permission to access your repositories. Check that:
1. You've authorized Galaxy in your Git provider's settings
2. The repository is under your personal account or an organization you're a member of
3. Try refreshing the page after granting access
Sometimes deployments take longer than expected. Check your app logs to see if the build is still running or if it's hit an error. If logs show the build completed but your app isn't responding, try:
1. Checking the Health Check Path configuration (make sure it's a valid endpoint)
2. Restarting your app from the dashboard
3. Reviewing your app's startup logs
This usually means your app isn't healthy or isn't listening on the correct port. Check:
1. Is your app actually running? (Check the app status in your dashboard)
2. Is it listening on the `PORT` environment variable?
3. Are there startup errors in your logs?
### Still stuck?
[Reach Galaxy support](/docs/getting-started/support) via live chat or email. Share your app name and recent logs, and we'll help you get unstuck.
***
## What's Next?
---
# Getting Help with Galaxy (https://help.galaxycloud.app/docs/getting-started/support)
***
## We're here when you need us
Deployments fail. Questions pop up. Features feel unclear. That's part of development, and we're here to help. When you hit a snag, Galaxy support is just a message away: real humans who understand what you're doing, ready to help with instant answers or detailed guidance.
***
## Check the status page first
Before reaching out, it's worth a quick look at the [Galaxy Status Page](https://status.galaxycloud.app). If there's an active incident or scheduled maintenance affecting the platform, you'll see it there. It's the fastest way to know whether an issue is on our end or yours.
Bookmark the status page. If your app suddenly behaves unexpectedly, checking it takes 5 seconds and can save you a lot of troubleshooting time.
***
## Choose your support channel
### Live chat for immediate help
Stuck on something right now? Our live chat connects you with a Galaxy team member in real time, no bots, no automation, just actual humans ready to help. Jump into your Galaxy dashboard, click the chat button in the corner, and start getting answers instantly.
Can't spot the chat button? Navigate to **Help & Support** → **Chat Support** and you're in.
Chat is perfect when you need quick guidance, urgent troubleshooting, or just want to talk through something with a real person.
**When support is most active:** 11am–9pm UTC, Monday–Friday. You'll get the fastest responses during these business hours.
### Email for in-depth issues
Some problems deserve a thoughtful, detailed response. Email support is your path for complex issues, feature deep-dives, or when you want to work on your own timeline.
Send your questions to [support@galaxycloud.app](mailto:support@galaxycloud.app) and we'll respond with comprehensive guidance, documentation, and examples tailored to your situation.
Email works best for technical issues that need back-and-forth discussion, or if you simply prefer asynchronous communication.
***
## Give us the information we need
Include these details when you reach out. It'll cut our resolution time in half:
* **Your Galaxy identifier**: your account email, username, or organization name
* **What's affected**: the specific service, application, database, or feature involved
* **What's happening**: a clear description of the issue or behavior you're seeing
* **Error messages**: copy and paste the exact error text if you have it
* **What you've tried**: the steps you've already taken to troubleshoot
* **Supporting details**: screenshots, logs, or API responses (especially for technical issues)
The more context you provide, the faster we can pinpoint the issue and get you moving again. A single well-formatted error message or log snippet often tells us everything we need to know.
---
# Email Security Verification (https://help.galaxycloud.app/docs/security-compliance/email-verification)
## Why Am I Seeing This?
Galaxy uses automated security checks to protect the platform from bots, spam accounts, and fraudulent signups. After you verify your email address, our system analyzes it for potential risks. This helps us avoid running unnecessary checks on users who never complete registration.
Sometimes, legitimate users get flagged. This doesn't mean you did anything wrong. It just means your email or account shares some characteristics with patterns our security system watches for.
No human decided to flag your account. Our security system analyzes hundreds of signals automatically. If you're a real person with a legitimate email, our support team can help you get access.
***
## What We Check
Galaxy's security system evaluates your email address using AI-driven analysis. Here's what it looks at (in plain terms):
* **Email deliverability**: Can your email actually receive messages? Is your inbox active and reachable?
* **Domain reputation**: How long has your email domain existed? Does it have proper authentication records (SPF, DKIM, DMARC)? Is it associated with known spam or fraud activity?
* **Email type**: Is your address from a free provider (like Gmail), a private domain (like yourcompany.com), or a disposable service (like Tempmail)?
* **Tagged addresses**: Does your email contain a `+` tag (like `user+signup@gmail.com`)? These are commonly used to create multiple accounts from a single inbox.
* **Role-based addresses**: Is your email a generic role address (like `hello@`, `support@`, `info@`, or `noreply@`) rather than a personal one?
* **Suspicious patterns**: Does your email address contain unusual characteristics, like random strings of numbers, gibberish text, or patterns commonly used by bots?
* **Risk scoring**: All these signals combine into a risk score. If the score crosses a threshold, your account is flagged for review.
We don't read your emails. We don't access your inbox. We only analyze publicly available information about your email address and domain.
The following email types are automatically blocked:
* **Disposable emails**: Temporary services like Tempmail, Guerrilla Mail, or 10 Minute Mail.
* **Tagged emails**: Addresses with a `+` tag (like `yourname+galaxy@gmail.com`).
* **Role-based emails**: Generic addresses like `hello@`, `support@`, `info@`, `admin@`, or `noreply@`.
If you're using any of these, you'll need to create a new account with a personal, permanent email address.
***
## What To Do If You're Flagged
If you've been flagged and you're a legitimate user, [contact our support team](/docs/getting-started/support). We can review your account manually and help you get access.
When you reach out, include your Galaxy username and the email address you used to sign up. Our team has access to the specific reasons your email was flagged and can explain what triggered the security check.
***
## Why Was I Flagged?
There are several reasons a legitimate user might trigger a security flag. None of these mean you're doing anything wrong.
* **New or unusual email domain**: If your email domain was recently registered or doesn't have complete authentication records, it may score higher on the risk scale.
* **Free email provider**: While most free email addresses are fine, some providers are more commonly used for fraudulent signups. This alone won't flag you, but it contributes to the overall assessment.
* **Tagged email address**: Email addresses with a `+` tag (like `user+something@gmail.com`) are blocked because they're commonly used to create multiple accounts from a single inbox.
* **Role-based email address**: Generic role addresses (like `support@yourcompany.com` or `info@yourcompany.com`) are blocked because they're typically shared inboxes, not personal accounts.
* **Email address patterns**: Addresses with lots of numbers, unusual characters, or random-looking strings can resemble bot-generated emails.
* **VPN or proxy usage**: If you're connecting from an IP address associated with VPNs, proxies, or data centers, this can add to your risk score.
* **Shared hosting or network issues**: Sometimes your IP address or network has been used for suspicious activity by others, affecting your assessment.
The security system weighs all these factors together. A single flag doesn't mean rejection. It's the combination that determines whether verification is needed.
***
## Common Questions
Security systems aren't perfect. They're designed to catch as many fraudulent signups as possible while minimizing friction for real users. Sometimes legitimate accounts share characteristics with risky ones. [Contact our support team](/docs/getting-started/support) and we'll review your account manually.
Yes. Our support team has access to the specific reasons your email was flagged. When you reach out, they can explain what triggered the security check and help you understand what happened.
The security check looks at many factors beyond just your email provider. Your specific email address, domain configuration, IP address, and other signals all contribute. Even accounts with reputable providers can be flagged if other signals raise concerns.
Disposable and temporary email addresses are automatically blocked. You'll need to create a new Galaxy account using a permanent email address from an established provider.
Tagged emails (like `yourname+galaxy@gmail.com`) are blocked because they're commonly used to create multiple accounts. Create a new Galaxy account using your base email address without the `+` tag.
Role-based emails are blocked because they're typically shared inboxes rather than personal accounts. Create a new Galaxy account using a personal email address tied to an individual.
If your current email was flagged, you can create a new Galaxy account with a different email address. Use a personal email from a well-established provider with proper authentication records. Avoid disposable services, tagged addresses, and role-based emails, as these are blocked automatically.
Absolutely. We only analyze publicly available information about your email address and domain. We don't access your inbox, read your messages, or collect personal data beyond what's necessary for account verification.
Our support team typically responds quickly. Once they review your account and confirm you're a legitimate user, access is restored promptly. Include your Galaxy username and email address when you reach out to speed things up.
***
## Why We Do This
Fraudulent accounts are a real problem for cloud platforms. Bots and bad actors abuse free tiers, consume resources, and create security risks for everyone. By verifying accounts proactively, we keep Galaxy safe and reliable for legitimate users.
This isn't about making your life harder. It's about protecting the platform you depend on.
If you're stuck or have questions about the verification process, [contact our support team](/docs/getting-started/support). We're available via live chat in your dashboard or email.
---
# GDPR and Data Protection (https://help.galaxycloud.app/docs/security-compliance/gdpr)
If you're serving users in Europe or handling personal data, GDPR matters. Galaxy takes data protection seriously and provides the tools and transparency you need to stay compliant.
Galaxy's infrastructure hosts your applications and databases. If your app handles personal data (like user accounts, contact info, or behavior tracking), GDPR applies to you. Galaxy assists with compliance obligations, but the responsibility for handling personal data correctly stays with you.
***
## What is GDPR?
The General Data Protection Regulation (GDPR) came into effect on May 25, 2018. It standardizes data protection rules across the European Union and gives EU residents significant rights over their personal data. Think of it as a framework that protects people's privacy while clarifying what companies can and can't do with their information.
GDPR applies to you if you're processing personal data (any information that identifies a person) of EU residents, even if your app or business is based elsewhere. It covers everything from user emails to location data, browsing history, and device identifiers.
***
## How Galaxy Helps You Stay Compliant
Galaxy has been GDPR-ready since before the regulation became enforceable, and we continue to enhance our processes and infrastructure to support your compliance obligations.
Galaxy processes data in a standardized, automated way across all deployments. We maintain infrastructure to meet our obligations as a data processor under GDPR.
Here's what that means for you:
**You Control the Processing**: As the data controller, you decide what data your app collects and how it's used. Galaxy acts as your data processor, handling the technical infrastructure. All data is processed according to your configuration.
**We Help with Data Subject Requests**: When EU users exercise their rights under GDPR (like requesting a copy of their data or asking for deletion), you can turn to Galaxy for assistance. We can help compile the personal data and delete it securely.
**Documentation and Assessments**: We conduct Data Protection Impact Assessments and can provide documentation about our processing activities. This helps you respond to regulatory inquiries or audits.
***
## Key Questions About GDPR at Galaxy
GDPR applies if you're processing personal data of EU residents. Personal data includes anything that identifies a person: names, emails, IP addresses, device IDs, location data, cookies, browsing history, or any custom data you're collecting.
If your app only processes non-personal data (like aggregate analytics or system logs), GDPR is less likely to apply. When in doubt, consult with a legal expert familiar with your app's specific use case.
Processing is any operation you perform on personal data: collecting it, storing it, using it, analyzing it, deleting it, or sharing it. If your app touches personal data in any way, you're processing it.
Galaxy processes data according to your app's configuration. We don't decide what gets processed, how long it's kept, or who accesses it. That's your responsibility as the controller.
A Data Subject Access Request (DSAR) is when a user asks to see what personal data you have about them. When you receive a DSAR, you can contact Galaxy support for assistance. Galaxy will help you compile the applicable personal data and handle the request on a case-by-case basis.
If a user requests deletion, you can ask Galaxy to securely delete their personal data. These requests are sensitive and handled on a case-by-case basis. We're committed to supporting you in meeting your data subject obligations.
If you're processing EU personal data with Galaxy, you should have a Data Processing Agreement in place. This legal document clarifies the relationship between you (controller) and Galaxy (processor).
Contact Galaxy support to request and sign a DPA if you don't have one already.
***
## Next Steps
GDPR compliance isn't one-and-done. It's about building data protection into how you design and run your app. Start by mapping what personal data you collect, why you need it, and how long you keep it. Then make sure your privacy policy is clear and accurate.
If you have specific compliance questions or need help with a Data Subject request, reach out to Galaxy support.
---
# Security & Compliance (https://help.galaxycloud.app/docs/security-compliance)
Galaxy takes security seriously. We protect the platform from fraudulent accounts, comply with international regulations, and maintain transparency about where our services are available.
If you've been flagged by our security system or have questions about service availability, [contact our support team](/docs/getting-started/support). We're here to help.
***
## Legal Documents
* [Data Processing Agreement](https://galaxycloud.app/legal/dpa/) – How we handle and process your data
* [Terms of Service](https://galaxycloud.app/legal/terms-of-service) – Our service terms and conditions
* [Privacy Policy](https://galaxycloud.app/legal/privacy-policy) – How we collect and use your information
* [Service Level Agreement](https://galaxycloud.app/legal/sla) – How we handle service availability
***
## Our Commitment
**Platform Protection**: We use automated security checks to prevent bots, spam accounts, and fraudulent signups from abusing the platform.
**Legal Compliance**: We follow international sanctions, trade restrictions, and local laws that govern where cloud services can operate.
**Transparency**: When something affects your account, we explain why and provide clear next steps.
**Support Access**: Our team can review flagged accounts manually and help legitimate users get access.
Security systems aren't perfect. If you're a legitimate user who's been flagged, our support team can help you get access.
---
# Service Availability and Geographic Restrictions (https://help.galaxycloud.app/docs/security-compliance/service-availability)
***
## Where Galaxy Operates
Galaxy isn't available everywhere. We'd love to serve the whole world, but legal requirements and international regulations determine where we can operate.
Our service availability depends on several factors:
* International sanctions and trade restrictions
* Local laws governing cloud services
* Regulatory compliance requirements
* Our ability to maintain secure infrastructure in a region
Services are not available to customers in specific geographic locations due to international sanctions and regulatory compliance requirements.
***
## What Gets Your Account Suspended
Your Galaxy account will be suspended if you register from a restricted region or if you add a payment method associated with a restricted region.
We use multiple detection methods internally, but what matters for you is straightforward: if Galaxy identifies you as being associated with a restricted region, your account will be suspended.
These restrictions apply uniformly across all customers, and we cannot make exceptions.
Registering from a restricted region or adding a payment method from a restricted region will result in account suspension. We legally cannot make exceptions regardless of individual circumstances.
***
## Why We Restrict Service in Some Regions
We don't make these decisions lightly. Galaxy restricts service when:
**Legal Compliance**: Operating in a region would violate international sanctions, trade restrictions, or local laws.
**Risk Management**: Continued service creates unacceptable legal or operational risks that we can't mitigate.
**Security Concerns**: Local conditions prevent us from delivering services securely or maintaining adequate compliance infrastructure.
**Payment Processing**: Payment processors can't operate in certain regions due to financial regulations.
These aren't business decisions. They're legal requirements we must follow.
***
## Compliance Framework
Galaxy maintains compliance with multiple legal frameworks:
* Domestic regulations in our country of incorporation
* International sanctions regimes
* Anti-money laundering (AML) and counter-terrorism financing (CTF) obligations
* Export control regulations
* Data protection and privacy laws
We update our policies as laws change. These aren't static rules.
***
## Common Questions
Your account was suspended because we detected you're associated with a region where we can no longer provide services due to regulatory compliance requirements. This happens when you register from a restricted region or when you add a payment method associated with a restricted region.
This is a legal compliance issue, not a billing or technical problem. We're required by law to suspend service in certain regions, and these requirements apply uniformly to all customers.
Unfortunately, no. These are legal compliance requirements that apply uniformly to all customers. We legally cannot make exceptions to sanctions compliance obligations, regardless of individual circumstances.
We understand this is frustrating, but exceptions would violate the laws we're required to follow.
Due to compliance requirements, we cannot provide services to customers who were previously served from restricted regions, even if you've relocated to a permitted country.
This policy exists to prevent compliance violations and ensure we meet our legal obligations.
[Contact our support team](/docs/getting-started/support). We'll discuss what options are available, though in some cases data access may no longer be possible after suspension.
Service availability is determined by applicable laws and regulations, which change over time. If legal requirements change, we'll update our policies accordingly.
We can't predict future changes to international sanctions or trade restrictions. Check this page periodically for updates.
***
## Your Responsibilities
When using Galaxy, you're responsible for:
**Accurate Information**: Provide truthful details about your payment method and geographic location. Misrepresenting either to bypass restrictions violates our terms of service.
**Local Compliance**: Ensure your use of Galaxy complies with all applicable laws in your jurisdiction. We handle international compliance obligations, but you're responsible for local legal requirements.
**Stay Informed**: Be aware of service availability in your region. If you travel or relocate, verify Galaxy is available in your new location before registering or updating payment methods.
Providing false information about your location or payment method to bypass restrictions violates our terms of service and may result in immediate account termination.
***
## Need Help?
Have questions about your account status or service availability in your region?
[Contact our support team](/docs/getting-started/support). We're here to help explain policies and answer questions.
**Important**: Support cannot override compliance-related restrictions or provide exceptions to this policy. These are legal requirements, not discretionary decisions.
This policy is subject to change based on evolving legal and regulatory requirements. We recommend reviewing this page periodically for updates.
---
# Systems Policy (https://help.galaxycloud.app/docs/security-compliance/systems-policy)
## Galaxy's Security Practices
Galaxy is committed to ensuring that the application code and data stored in the Galaxy platform is accessible only by authorized individuals. Security best practices are employed consistently and evolve to meet the needs of our customers.
When you sign up, you agree to our [standard SLA](https://galaxycloud.app/legal/sla). If you need a customized SLA for your account, reach out to [Galaxy Support](/docs/getting-started/support).
***
## Platform Architecture
Galaxy's physical infrastructure is hosted and managed in secure data centers operated by leading cloud providers, including Amazon Web Services (AWS) and OVHCloud.
Galaxy is composed of platform services built and run on top of cloud infrastructure provided by our partners. Most container orchestration is managed by the Galaxy team using modern, secure, and widely adopted tools available on the market. In specific scenarios, managed orchestration services provided directly by the cloud provider are also used.
Galaxy employs container-level isolation mechanisms to ensure separation of resources, processes, and environments between applications. These mechanisms are combined with container orchestration technologies such as Docker and RKE2. Each customer application runs in its own isolated container on dedicated virtual servers within our cloud infrastructure.
***
## Risk Assessment
Our cloud providers continually manage risk and undergo recurring assessments to ensure compliance with industry standards.
Our cloud providers' data center operations have been accredited under:
* ISO 27001
* SOC 1 and SOC 2/SSAE 16/ISAE 340
* PCI DSS
* GDPR compliance
Galaxy itself has not yet obtained independent certifications. SOC 2 Type II and ISO 27001 are targeted for 2026.
***
## Policy around Software Security Updates
System configuration and consistency are maintained through standard images, configuration management software, and the replacement of select systems with updated deployments.
Systems are deployed using up-to-date images that are updated with configuration changes and security updates before deployment. Once deployed, existing systems are decommissioned and replaced with up-to-date systems.
***
## Customer Data Security
Customer application configuration secrets are stored in a Galaxy system database. This database is secured by standard system and authorization policies. Access to the database is restricted to authorized personnel only, for purposes of administration and support.
Customer application certificates and keys are stored in encrypted form in the Galaxy system database. These certificates are only decrypted on the Galaxy Proxy machines and are not exposed to application containers.
Access to private information is protected using Docker isolation in the application container.
***
## Application Data
Galaxy provides SSL encryption to protect data transmission over the wire from external entities to the Galaxy Proxy layer. Internally in Galaxy, virtual machine and Docker container network isolation is utilized to protect data transmission over the wire.
Galaxy does not maintain databases that are utilized for production application use. These databases are provisioned, configured, and maintained by the customer.
Galaxy free MongoDB databases are only available for hobby projects and open-source demos.
***
## Application Logs
Galaxy captures and stores Application Logs in an off-site database. This database is secured by standard system and authorization policies. Access to the database is restricted to authorized personnel for administration and support only.
***
## Operational Policies
Galaxy employees do not access customer data or customer environments as part of day-to-day operations. When customers need support, authorized employees are able to view customer data when specifically requested.
All company employees are trained to understand that customer data privacy and confidentiality are paramount. Under no circumstances is customer data ever disclosed to a third party. Only a limited subset of employees have the ability to view customer environments and stored data.
Access is routinely evaluated to ensure those rights are retained only when necessary by job function. Galaxy maintains a policy and operational checklist for removing access for employees that are no longer associated with its operations.
***
## Two-Factor Authentication
Meteor Developer Accounts support Two-Factor Authentication, so we recommend that all members of your organization have it enabled.
You can check if all members of your organization have this enabled in your Members tab on your account page on Galaxy. You will see a lock icon on each member with Two-Factor Authentication enabled.
Each member can enable Two-Factor Authentication on their Settings > Security Information.
It's important to save the backup codes in a safe place as well.
Our two-factor authentication works via email or authenticator app, so you will receive a code by email or app when you authenticate with your confirmation code.
If you authenticate with GitHub, the confirmation code will not be sent as you should have two-factor on GitHub as well. So our two-factor is not going to do anything in the GitHub authentication.
***
## DNSSEC
Starting from June 22, 2021, meteor.com is a domain with DNSSEC enabled. Check what DNSSEC is, and why it's important [here](https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en).
***
## What's Next?