⚡️ A simple, easy way to deploy static websites to Amazon S3.
A simple, easy way to deploy static websites to Amazon S3
.htmlextensions)
Install it globally:
$ npm install --global @static/discharge
Or add it to your application’s
package.json:
$ npm install --save-dev @static/discharge
Configuring AWS credentials can be a bit confusing. After getting your Access Key ID and Secret Access Key from AWS, you should store them in a file at
~/.aws/credentials. It should look something like this:
[default] aws_access_key_id=AKIAIOSFODNN7EXAMPLE aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Replace the example keys with your own.
Alternatively, if you prefer environment variables or you are running Discharge in an automated environment like a continuous integration/deployment server you can omit the
aws_profileconfiguration option explained later and set environment variables instead.
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Replace the example keys with your own.
Configuration is done via a
.discharge.jsonfile located at the root of your application. You can run
discharge initto get an interactive UI that will help you generate the configuration file, or you can write it yourself from scratch. It will look something like this:
{ "domain": "anti-pattern.com", "build_command": "bundle exec middleman build", "upload_directory": "build", "index_key": "index.html", "error_key": "404.html", "cache": 3600, "aws_profile": "website-deployment", "aws_region": "us-west-1", "cdn": true, "dns_configured": false }
Those are most of the configuration options but a complete list is next.
There are no defaults—all configuration options are explicit and must be provided unless marked as optional.
domain
String
The domain name of your website. This will be used as the name of the S3 bucket your website will be uploaded to.
build_command
String
The command that will be executed in the shell to build your static website.
upload_directory
String
The name of the directory that the
build_commandgenerated with the static files in it. This is the directory that will be uploaded to S3.
index_key
String
The key of the document to respond with at the root of the website.
index.htmlis almost certainly what you want to use. For example, if
https://example.comis requested,
https://example.com/index.htmlwill be returned.
error_key
String
The key of the document to respond with if the website endpoint responds with a 404 Not Found. For example,
404.htmlis pretty common.
cache
Number(optional when
cache_controlis set)
The number of seconds a browser should cache the files of your website for. This is a simplified version of the HTTP
Cache-Controlheader. If you set it to
0the
Cache-Controlwill be set to
"no-cache, no-store, must-revalidate". If you set it to a positive number, say,
3600, the
Cache-Controlwill be set to
"public, max-age=3600".
Be careful about setting too high a cache length. If you do, when a browser caches it, if you then update the content, that browser will not get the updated content unless the user specifically hard-refreshes the page.
When
cdnis enabled, the
s-maxagedirective is included and set to a very high number (one month). It is recommended you set
cacheto a very low number (e.g five minutes). The CDN will use the
s-maxagedirective and the browser will use the
max-agedirective. This works because when you deploy the CDN’s cache will be automatically expired. For more information see the
distributecommand.
If you need finer-grained control over the
Cache-Controlheader, use the
cache_controlconfiguration option.
cache_control
String(optional)
A
Cache-Controldirective as described in the HTTP documentation. This is for more advanced, finer-grained control of caching. If you don’t need that, use the
cacheconfiguration option.
The
s-maxagedirective added to
cachewhen
cdnis enabled is not added here—you have to do it yourself. Caveat emptor.
redirects
Array(optional)
String
The URL path prefix to match on. The redirects are matched in order, so if you have two paths with similar parts, like
some/pageand
some, make sure you put the more specific path first.
String
The path to redirect to if the
prefix_matchmatches.
AWS does not allow the
prefix_matchand
destinationto start with a forward slash (
/some/page). You can include them in the configuration for your convenience, but the forward slashes will be invisibly removed when configuring the bucket.
If you need finer-grained control over the routing rules, use the
routing_rulesconfiguration option.
routing_rules
Array(optional)
If the
redirectsconfiguration is not enough, you can declare more complex routing rules. There are some horrible AWS docs that explain the available options and here’s an example of the syntax from the AWS JavaScript docs.
[ { Redirect: { /* required */ HostName: "STRING", HttpRedirectCode: "STRING", Protocol: "http" || "https", ReplaceKeyPrefixWith: "STRING", ReplaceKeyWith: "STRING" }, Condition: { HttpErrorCodeReturnedEquals: "STRING", KeyPrefixEquals: "STRING" } }, /* more items */ ]
The unusual property casing is intentional—the entire configuration will be passed directly through in the HTTP request.
cdn:
Boolean
Set this to
trueif you want to use a CDN and HTTPS/TLS. Setting up the CDN does not happen automatically when deploying. After deploying, run
discharge distributeto set up the CDN. Once the CDN is set up, future deploys will expire the CDN’s cache.
For more information see the
cacheconfiguration or the
distributecommand.
aws_profile
String(optional)
The AWS profile you’ve specified in a credentials file at
~/.aws/credentials.
If you only have one set of credentials then specify “default”.
If you want to create a new AWS user with specific permissions/policies for deployment, you can add another profile in the credentials file and specify the custom profile you’ve added.
If you prefer environment variables or you are running Discharge in an automated environment like a continuous integration/deployment server you can omit this configuration option.
aws_region
String
The Amazon S3 region you want to create your website (bucket) in.
dns_configured
Boolean
If you run
discharge initthis will be set to
falseautomatically. Then when you run
discharge deployit will show the record you need to add to your DNS configuration. The deploy command will then automatically set this value to
true, assuming you have properly created the DNS record.
After you’ve finished configuring you can run
discharge deployto deploy. Deploying is a series of steps that are idempotent—that is, they are safe to run over and over again, and if you haven’t changed anything, then the outcome should always be the same.
If you change your website configuration (
cache,
redirects, etc.) it will be updated. If you change your website content, a diff will be done to figure out what needs to change. New files will be added, changed files will be updated, and deleted files will be removed. The synchronization is one way—that is, if you remove a file from S3 it will just be re-uploaded the next time you deploy.
Clean URLs are when the
.htmlextensions are dropped from URLs for aesthetic or functional reasons. The
.htmlextensions are now commonly considered superfluous. If you have a file named
/projects.htmlit’s now understood and generally preferred that the URL
domain.com/projectswould serve that file.
When you deploy, two copies of each HTML file will be uploaded: one with the
.htmlextension and one without. So a file
some-page.htmlwill be uploaded as
some-page.htmland as
some-page, which will allow it to be served from
https://example.com/some-page.html, with the extension, or from
https://example.com/some-page, without the extension. You are free to use whichever URL style you prefer!
After you’ve finished deploying you can run
discharge distributeto distribute your website via a CDN (content delivery network). The command will create a TLS certificate, ensure it’s verified, create a distribution, and ensure it’s deployed. Almost no configuration necessary[1]. This step is completely optional, but if you have a high-traffic website it’s highly recommended, and if you want to secure your website with HTTPS/TLS then you have to do it[2].
A CDN is a caching layer. It can significantly speed up requests for users located geographically farther from where your website is deployed, and sometimes even for users nearby it. In brief, the way a CDN works is you point your DNS to the CDN. When a request comes in, the CDN relays the request to your origin (in this case S3) then takes the response and caches it according to the
Cache-Controlheader in the response. Future requests will only hit the CDN and not your origin, until either the CDN’s cache expires or it’s expired early.
The
Cache-Controlheader can specify two different cache lengths, one for the CDN and one for the browser. Because static sites are… static, the only times they change are when deployed, so it’s safe to set a very high cache length for the CDN, a low cache length for the browser, and then expire the CDN’s cache early when deploying.
[1]: CDNs can be configured in a lot of different, complex ways. The goal was to abstract away all of that—choose sane defaults and require no configuration. I think this will work for the vast majority of people, but if there’s a specific reason you need more flexibility let me know, and if it’s widely-needed we can add it.
[2]: While CDNs can be configured without TLS, given that TLS certificates are free and we want the entire web to be encrypted, I can’t see any reason to support not using TLS.
Verifying the TLS certificate is done via email. AWS will look up the contact information in the WHOIS database for your domain and then send a verification email to the following email addresses:
Inexplicably, the .io domain registrar is the only registrar that does not return contact information from the WHOIS database. That means you have to have one of the five common system email addresses set up on a .io domain or you will not receive the TLS certificate verification email.
You can use any domain, subdomain, or combination you like. You just need to configure your DNS appropriately.
If you want to use a naked domain (
domain.com), because S3 and CloudFront expose a special URL rather than an IP address, your DNS provider will need to support ALIAS records; not all do.
If you want to use a subdomain like
www.domain.comor
blog.domain.com, create a CNAME record for it. The TLS/HTTPS certificate is created for the root domain and all subdomains via a wildcard.
If you want to use both a naked domain and a subdomain, create an ALIAS and a CNAME record.
If you want to use only a naked domain or a subdomain, but redirect one to the other (like redirect
www.domain.comto
domain.com), then the easiest way to do that is to add a redirect at the DNS-level. It’s not technically a part of the DNS specification so not all DNS providers have it, but the vast majority do. If yours does not, you can either switch to a DNS provider that does or manually create an S3 bucket that does the redirect and create an ALIAS or CNAME record pointing to it.
Bug reports and pull requests are welcome on GitHub at https://github.com/brandonweiss/discharge.
The package is available as open source under the terms of the MIT License.