Learn how to configure DNS to point to Galaxy

Before users can access your application, you must configure your DNS records to point to Galaxy. Galaxy is not a DNS provider and you’ll need to use your existing DNS provider to set DNS records. While the process will be specific to your DNS provider, the general method is the same.

We also provide a free subdomain option if you don’t need to have your own domain.

The standard DNS setup for Galaxy is to use a subdomain with a CNAME record to point to Galaxy and redirect your root (also called the naked or apex domain) domain to this subdomain. In the next sections we will guide you on how to do this.

Hosting on a subdomain with CNAME

Configure your subdomain, for example, www.mycompany.com or app.mycompany.com adding a CNAME record to your DNS provider.

Galaxy provides different regions around the world, fill your CNAME record value for your subdomain with the region that you are using:

  • US East: us-east-1.galaxy-ingress.meteor.com.

  • EU West: eu-west-1.galaxy-ingress.meteor.com.

  • Asia-Pacific: ap-southeast-2.galaxy-ingress.meteor.com.

If you don’t know where to configure this we recommend that you use Route 53 as your DNS provider, follow the steps here.

Ensure the hostname you deployed to matches the fully qualified domain name of your app (i.e app.mycompany.com).

We recommend you use SSL as a best practice. You can either enable LetsEncrypt using our integration or upload your own certificate.

By default, when deploy an app for the first time, Galaxy will always try to enable LetsEncrypt on your domain, as well as enable the SSL to force your domain redirect to the HTTPs protocol.

Hosting on a Root Domain using an A Record

If the DNS provider you’re using doesn’t support ANAME or ALIAS records, or CNAME flattening, don’t worry. You can easily resolve this by adding an A record to point to your apps on Galaxy. A records are used to point to IP addresses and you can easily access your app's settings on Galaxy by going to the Domains & HTTPS section and point your Root Domain to the IP that is shown to you.

After waiting for DNS propagation, don’t forget to click on Add New Domain and fill in your Root Domain (mycompany.com). After finishing the process, you may click on the Generate certificate button to activate HTTPS for your Root Domain and choose to force redirection from HTTP to HTTPS for your Root Domain as well. This will ensure increased security for your application.

Hosting on a root domain using ALIAS

In this scenario, you do want to emphasize a short URL like mycompany.com. While hosting on a root domain can introduce complications, it’s possible to do by using an ALIAS (also called an ANAME record).

First, you’ll need to either deploy your app to the root domain (e.g myapp.com) or add the root domain as an additional domain for your app. Next, you will need to add an ALIAS record to your DNS provider that points your root domain to galaxy-ingress.meteor.com.

Not all DNS providers support this feature and the implementation is usually very specific to each provider. Providers we know and recommend are:

Note: If you decide to host directly on a root domain, you will likely want to forward www to your root domain by setting up URL redirection (see above).

We recommend you use SSL as a best practice. You can either enable LetsEncrypt using our integration or upload your own certificate.

Redirecting the root domain (outdated)

You can now easily direct your root domain to our servers. See the section above. This section is here only as a reference in case your app was configured before this feature was available.

A common scenario is when your app is hosted at www.mycompany.com or app.mycompany.com and you’d like mycompany.com to redirect to the same app running in your subdomain.

Here we are going to explain step-by-step how to redirect your root domain using AWS S3, AWS CloudFront, AWS Certificate Manager and AWS Route 53 services.

You can do this configuration in other providers, we are explaining AWS here in details because it is the most popular one.

AWS Setup

We are going to do the following steps:

  • Make sure your DNS is managed by AWS Route 53.
  • Create a bucket on AWS S3: it redirects the root domain to your app subdomain.
  • Create a Certificate on AWS Certificate Manager: it provides SSL Certificate to your app root domain.
  • Create a CloudFront distribution on AWS CloudFront: it provides an endpoint to be used in the A Record (your root domain).
    • The bucket from the step above will be used here as the endpoint.
    • The certificate from the step above will be used here as the certificate.
  • Create a new A Record providing an Alias between the root domain and the CloudFront distribution: it provides, finally, the redirect that we want from your root domain to your app subdomain.

Let’s see how to do this.

AWS Route 53

You need to set your DNS to be controlled by AWS Route 53.

Go to your AWS Console and go to the service called Route 53. If you don’t have an account on AWS can create one here.

In the Route 53 Dashboard click on Create Hosted Zone, fill your Domain Name (mycompany.com) and click on Create.

You are going to see a list of records, copy the value from NS (Name server). You are going to need it soon.

The value will be like


but don’t copy these hosts from here, copy from your AWS Route 53 record because they are probably different.

Go to the service where you bought your domain and replace your Name Server, sometimes called DNS Servers or DNS Provider, to use Route 53 pasting the name servers that you have copied from AWS Route 53.

From now on every change in your DNS should be done in Route 53 as it is now your DNS Provider.

Every service that sells domains, like GoDaddy, have a different way to set the Name Servers (DNS Provider) but it is usually very easy to find it, if you have any questions about this contact your domain seller support.

Now that you are using AWS Route 53 as your DNS Provider you can point your subdomain (app.mycompany.com or www.mycompany.com) to Galaxy following the steps here. After you complete your subdomain setup return to the next step below to redirect your root domain.


Now we are ready to start the setup to make your root domain to redirect automatically to your subdomain. Go to S3 Dashboard. Click on Create bucket, fill your bucket name with your root domain (mycompany.com), uncheck Block all public access, check I acknowledge that the current settings might result in this bucket and the objects within becoming public. and click on Create bucket.

Access your newly created bucket (mycompany.com) and go to Properties tab, scroll down to Static website hosting section, click on Edit. Enable it and check the Hosting type as Redirect requests for an object in the field Host name fill your subdomain (www.mycompany.com or app.mycompany.com) and select the protocol https, click on Save.

Still in the Properties tab, scroll down again to Static website hosting section and copy the Bucket website endpoint it should look like http://mycompany.com.s3-website-us-east-1.amazonaws.com.

AWS Certificate Manager

Now go to AWS Certificate Manager and click on Request a new certificate. Select Request a public certificate, then in the next step inform your root domain AND(important!) the www one as well. As the Fully qualified domain name, keep DNS validation checked and click on Request. Your certificate was requested but you still need to create the record in Route 53 to allow AWS to confirm your ownership of the domain. If you go inside your Certificate details you can click in the button Create records in Route 53 and then AWS is going to create the necessary record for you. Now you need to wait AWS to validate your certificate. It can take up to 15 minutes. You should refresh the list of certificates until you see your new certificate as Issued in the Status column.

AWS CloudFront

Your certificate is ready so you can proceed to create your CloudFront Distribution. Click on Create Distribution, fill the field Origin domain with the Bucket website endpoint that we’ve copied in the previous section and fill a friendly name for your distribution in the field Name.

Scroll down until you see Default cache behavior, for the Viewer Protocol Policy select Redirect HTTP to HTTPS.

For Allowed HTTP methods choose which suits your needs best, usually GET, HEAD, OPTIONS should be enough.

For Cache key and origin requests select Legacy cache settings and don’t change anything else.

Scroll down to Settings, on Alternative domain name (CNAME) click on Add item and fill your root domain (mycompany.com) AND(important!) the www one as well(www.mycompany.com). In Custom SSL certificate select the certificate that you created in the previous step.

Then click on Create distribution. It will take up to 15 minutes to be ready, make sure you check the distributions list until you see Enabled in the Status column.

AWS Route 53 - A Record

Now you need to return to Route 53 to create a record set type A for mycompany.com and toggle the Alias to enable it and select Alias to CloudFront distribution, choose the CloudFont distribution that you created in the previous step. Then click on Save.

Included *.meteorapp.com

You are free to use Galaxy’s built-in domain names. SSL is enabled on these domains by default.

If you’re in the US region (galaxy.meteor.com), deploy your example app to example.meteorapp.com.

If you’re in the EU region (eu-west-1.galaxy.meteor.com), deploy your example app to example.eu.meteorapp.com.

If you’re in the Asia-Pacific region (ap-southeast-2.galaxy.meteor.com), deploy your example app to example.au.meteorapp.com.

Substitute in the actual name of your app for ‘example’. Beyond that, no DNS configuration is necessary; Galaxy handles all of this for you.

Note: example.meteor.com is not available. You cannot deploy to meteor.com domains.

DNS propagation

DNS is distributed and cooperative, and it takes time for the world to see your changes. In many countries, it usually updates within about 30 minutes, but it can take up to 24 hours or even longer in some circumstances (depending on the record’s TTL).

You can check if your ALIAS or ANAME or CNAME setting was successful in the terminal by typing dig +show www.mycompany.com. If your ANSWER SECTION includes a record like this, you are in good shape:

www.mycompany.com.    1800   IN    CNAME        galaxy-ingress.meteor.com.

Testing your DNS changes

A quick way to test that your app is working is by modifying the /etc/hosts file to resolve your app’s hostname to the Galaxy load balancer’s IP address directly. Note that this will only affect your local machine.

To find out which IP address to use, type dig +short galaxy-ingress.meteor.com and choose any of the ones shown. The IP addresses used by Galaxy’s load balancer are likely to change, so you may need to do this process more than once.

Add a line to /etc/hosts (Windows: c:\windows\system32\drivers\etc\hosts) that contains:

[Galaxy's current ip address]   [Your app's hostname, e.g app.mycompany.com]

To ensure your changes take effect, you can reset your computer’s local DNS cache with sudo dscacheutil -flushcache (Mac; see other OSes) after making your changes.

Other options for redirecting the root domain

While the way to do this varies by DNS provider, these are common methods:

Because another service is hosting the redirect page, you’ll need to set up SSL using their methods, which will most likely involve a certificate upload.

If you’d like to host on Galaxy on the naked domain with HTTPS, or would like to serve a redirect from Amazon S3 via Amazon CloudFront (which supports custom certs), this guide, from a member of the DNSimple team, may be helpful.

Other issues

Galaxy is not a DNS record provider. Our support is focused on configuring your settings to work with Galaxy apps, as described in the sections above.

If you have additional issues which reach beyond the scope of this article, you may need to contact your DNS record provider to resolve them.

Edit on GitHub
// search box