Skip to content
GRIMOIRY

Point a domain at a server

$ grim infra:dns example.com --alias=vps1 --provider=cloudflare

The server has an address and the domain does not point at it yet. What stands between them is two records in a DNS panel that grim cannot log in to, so this is the one command in the family that changes nothing anywhere. grim infra:dns prints exactly what to enter, in the words your provider's screen uses, and later tells you whether the world can see it.

Do this before the first project goes on the server. Let's Encrypt only issues a certificate for a name that already resolves to the machine.

Usage

$ grim infra:dns example.com                                       # the records, in zone-file form
$ grim infra:dns example.com --alias=vps1 --provider=cloudflare    # the same, as Cloudflare form fields
$ grim infra:dns example.com --ip=203.0.113.10                     # for a server grim has no record of
$ grim infra:dns example.com --alias=vps1 --check                  # are they live yet

Run it from anywhere. With exactly one server made by grim infra:aws-ec2 on record, the alias is optional. --alias also accepts any other server in ~/.grim/servers.json, and --ip needs no record at all.

Arguments and options

Print recommended DNS records for a grim-managed server (Cloudflare / Route 53 / zone file)

Usage

grim infra:dns [--alias ALIAS] [--ip IP] [--provider PROVIDER] [--ttl TTL] [--check] [--] <domain>

Arguments

Argument Description
domain Domain to point at the server (e.g. example.com) (required)

Options

Option Description
--alias=ALIAS Server alias (defaults to the only grim-managed server when there is exactly one)
--ip=IP Override the target IP (escape hatch when no servers.json entry exists yet)
--provider=PROVIDER Output style: generic | cloudflare | route53 (default: generic)
--ttl=TTL TTL in seconds for the records (default: 300)
--check Also dig the live records and report drift

What it actually does

  1. Resolves the target IP. From --ip, or the server named by --alias, or the only grim-made server on record.
  2. Prints the two records. An A record for the domain itself and a wildcard A record for everything under it, both to the server's address, with a TTL of 300 seconds or --ttl. A TTL below 60 is raised to 60.
  3. Prints the provider section. generic describes what a registrar's panel asks for. cloudflare lists both records field by field. route53 prints the aws route53 commands to create the zone and the records, and saves the change batch as grim-dns-<hash>.json in your system's temp directory so the second command can read it.
  4. Checks, with --check. Runs dig for the domain, www. and app. and marks each: resolves to the server, resolves elsewhere with the address expected, or no record yet. Without --check it ends with the check command to run later.

The wildcard is enough for every subdomain you will add. Certificates are issued per host name over HTTP, so no TXT records are involved.

Pitfalls

Cloudflare's proxy blocks the first certificate

With the orange cloud on, Cloudflare answers for your domain and the Let's Encrypt challenge never reaches the server. Create both records as DNS only, the grey cloud. Once the site has its certificate you can switch the proxy on, and then set SSL/TLS mode to Full (strict).

The panel refuses *

Some registrars do not accept a wildcard record. Add an A record for each subdomain you use instead: app, staging, and so on.

More than one server on record

Multiple grim-managed servers exist — pick one with --alias=vps1 | vps2 means the command will not guess. Pass the alias. grim infra:list shows them.

--check says nothing about the records

dig not installed — install bind-tools / dnsutils to enable --check. is printed in place of the results when dig is missing. Install it, or query the name with any other resolver tool.

no A record yet (may still be propagating) right after you saved the records is normal. A new zone or changed nameservers can take hours to be visible everywhere. Check again before you look for a mistake.

After it finishes

Nothing has changed anywhere, so the work is yours: enter the records, wait, check.

$ grim infra:dns example.com --alias=vps1 --check

When the domain resolves to the server, put a project on it with grim server:add-project. The recipe First deploy to a fresh VPS carries on from here.

Questions

Does it work for a server that is not on AWS?

Yes. Nothing in it is specific to AWS. Pass --alias for any server in servers.json, or --ip for any IPv4 address.

Can it create the records for me?

No. It has no access to your DNS provider and asks for none. For Route 53 it gets closest: the commands it prints are complete apart from the zone id.

grim infra:list

Survey what runs on AWS

List every server and AWS resource grim has created, with a monthly cost estimate for each and the ids that infra:destroy takes.

grim infra:doctor

Check the way to AWS

Check that the aws CLI, terraform and working AWS credentials are in place, and print the setup steps for whatever is missing.

grim infra:aws-ec2

Raise a server on AWS

Create one EC2 instance with a static address, a firewall and your SSH key in your AWS account, then hand it to grim server:setup.

grim server:add-domain

Add a second domain

Serve a deployed project on one more domain, with the vhost, the Traefik rule and the certificate widened to cover it.

grim server:add-project

Give a project a home

Prepare one environment of a project on a production server, with its database, nginx vhost, certificate, compose stack and .env.

Recipes that use it

First deploy to a fresh VPS

Take a bare Ubuntu or Debian server and a project that runs on your machine, and end with the project live on its own domain over HTTPS.