Module documentation for 220.127.116.11
Deployment system for web applications, originally intended for hosting Yesod applications. Keter does the following actions for your application:
- Binds to the main port (usually port 80) and reverse proxies requests to your application based on virtual hostnames.
- Provides SSL support if requested.
- Automatically launches applications, monitors processes, and relaunches any processes which die.
- Provides graceful redeployment support, by launching a second copy of your application, performing a health check, and then switching reverse proxying to the new process.
- Management of log files.
Keter provides many more advanced features and extension points. It allows configuration of static hosts, redirect rules, management of PostgreSQL databases, and more. It supports a simple bundle format for applications which allows for easy management of your web apps.
Do get Keter up-and-running quickly on an Ubuntu system, run:
wget -O - https://raw.githubusercontent.com/snoyberg/keter/master/setup-keter.sh | bash
(Note: you may need to run the above command twice, if the shell exits after
apt-get but before running the rest of its instructions.) This will download
and build Keter from source and get it running with a
default configuration. By default Keter will be set up to also support HTTPS, and
will require you to provide a key and certificate in
/opt/keter/etc. You can
disable HTTPS in
/opt/keter/etc/keter-config.yaml by commenting the certificate
and key lines.
This approach is not recommended for a production system. We do not recommend
installing a full GHC toolchain on a production server, nor running such ad-hoc
scripts. This is intended to provide a quick way to play with Keter, especially
for temporary virtual machines. For a production system, we recommend building
keter binary on a separate system, and tracking it via a package manager
or similar strategy.
Bundling your app for Keter
Modify your web app to check for the
PORTenvironment variable, and have it listen for incoming HTTP requests on that port. Keter automatically assigns arbitrary ports to each web app it manages. The Yesod scaffold site is already equipped to read the
PORTenvironment variable when it is set.
Create a file
config/keter.yaml. The minimal file just has two settings:
exec: ../path/to/executable host: mydomainname.example.com
See the bundles section below for more available settings.
Create a gzipped tarball with the
config/keter.yamlfile, your executable, and any other static resources you would like available to your application. This file should be given a
.keterfile extension, e.g.
/opt/keter/incoming. Keter will monitor this directory for file updates, and automatically redeploy new versions of your bundle.
Instructions are for an Ubuntu system. Eventually, I hope to provide a PPA for this (please contact me if you would like to assist with this). For now, the following steps should be sufficient:
First, install PostgreSQL
sudo apt-get install postgresql
Second, build the
keter binary and place it at
/opt/keter/bin. To do so,
you’ll need to install the Haskell Platform, and can then build with
This would look something like:
sudo apt-get install haskell-platform
cabal install keter
sudo mkdir -p /opt/keter/bin
sudo cp ~/.cabal/bin/keter /opt/keter/bin
Third, create a Keter config file. You can view a sample at https://github.com/snoyberg/keter/blob/master/etc/keter-config.yaml.
Fourth, set up an Upstart job to start
keter when your system boots.
start on (net-device-up and local-filesystems and runlevel )
stop on runlevel 
exec /opt/keter/bin/keter /opt/keter/etc/keter-config.yaml
Finally, start the job for the first time:
sudo start keter
Optionally, you may wish to change the owner on the
folder to your user account, so that you can deploy without
sudo mkdir -p /opt/keter/incoming
sudo chown $USER /opt/keter/incoming
An application needs to be set up as a keter bundle. This is a GZIPed tarball
.keter filename extension and which has one special file:
config/keter.yaml. A sample file is available at
Keter as well supports wildcard subdomains and exceptions, as in this example configuration:
- host: static.example.com
- from: example.com
Due to YAML parsing, wildcard hostnames will need to be quoted as above.
Wildcard hostnames are not recursive, so
foo.bar.example.com must be
explicitly added as an extra hostname in the above example, or
*.*.example.com would cover all host names two levels
deep. It would not cover host names only one level deep, such as
qux.example.com. In this manner, wildcard hostnames correspond to the
manner in which SSL certificates are handled per RFC2818. Wildcards may
be used in only one level of a hostname, as in
Full RFC2818 compliance is not present -
f*.example.com will not be
handled as a wildcard with a prefix.
A sample Bash script for producing a Keter bundle is:
rm -rf static/tmp
tar czfv yesodweb.keter dist/build/yesodweb/yesodweb config static
For users of Yesod, The
yesod executable provides a
keter command for
creating the bundle, and the scaffolded site provides a
In order to deploy, you simply copy the keter bundle to
To update an app, copy in the new version. The old process will only be
terminated after the new process has started answering requests. To stop an
application, delete the file from incoming.
Keter ships by default with a PostgreSQL plugin, which will handle management of PostgreSQL databases for your application. To use this, make the following changes:
- Add the following lines to your
plugins configuration option was added in v1.0 of the
keter configuration syntax. If you are using v0.4 then use
Modify your application to get its database connection settings from the following environment variables:
The Yesod scaffold site is already equipped to read these environment variables when they are set.
There are reports of Keter not working behind an nginx reverse proxy. From the reports, this appears to be a limitation in nginx’s implementation, not a problem with Keter. Keter works fine behind other reverse proxies, including Apache and Amazon ELB.
One possible workaround is to add the following lines to your nginx configuration:
proxy_set_header Connection ""; proxy_http_version 1.1;
This has not yet been confirmed to work in production. If you use this, please report either its success or failure back to me.
Keter does not handle password-protected SSL key files well. When provided with such a key file, unlike Apache and Nginx, Keter will not pause to ask for the password. Instead, your https connections will merely stall.
To get around this, you need to create a copy of the key without password and deploy this new key:
openssl rsa -in original.key -out new.key
(Back up the original key first, just in case.)
Stanza-based config files
Starting with Keter 1.0, there is an alternate format for application Keter config files, which allows much more flexibility in defining multiple functionality for a single bundle (e.g., more than one web app, multiple redirects, etc). This README will eventually be updated to reflect all various options. In the meanwhile, please see the following examples of how to use this file format:
Multiple SSL Certificates
Keter is able to serve different certificates for different hosts, allowing for the deployment of distinct domains using the same server. An example
keter-config.yaml would look like::
- host: "*4" # Listen on all IPv4 hosts
- host: 127.0.0.1
- host: 127.0.0.2
- Keter spawns multiple failing process when run with
sudo start keter.
- This may be due to Keter being unable to find the SSL certificate and key.
Try to run
sudo /opt/keter/bin/keter /opt/keter/etc/keter-config.yaml. If it fails with
keter: etc/certificate.pem: openBinaryFile: does not existor something like it, you may need to provide valid SSL certificates and keys or disable HTTPS, by uncommenting the key and certificate lines from
- This may be due to Keter being unable to find the SSL certificate and key. Try to run
Bug fix: catch exceptions during reload #64
- Add ability to use middleware #63
More correct/complete solution for issue #44. Allows looking up hosts either with or without port numbers.
Partial workaround for keter.yaml files that give a port with the hostname.
Fix bug where the cleanup process would remain running.
All stanzas may have the
requires-secure property to force redirect to HTTPS. You can set additional environment variables in your global Keter config file.
Support for overriding external ports. Support for keter.yml in addition to keter.yaml. Case insensitive hostname lookups.
Set the X-Forwarded-Proto header
Enable GZIP middleware
Upgrade to WAI 3.0
Upgrade to conduit 1.1
Permit use of wildcard subdomains and exceptions to wildcards. Convert internal strings to use Data.Text in more places. (Although internationalized domain names are not supported unless entered in punycode in configuration files.)
Significant overhaul. We now support monitoring of much more arbitrary jobs (e.g., background tasks), have a proper plugin system (PostgreSQL is no longer a required component), and have a much better system for tracking hostname mapping changes.
Switch to fsnotify to get cross-platform support. No longer using raw proxies, but instead WAI proxies.
Sending a HUP signal reloads the list of deployed apps. This is useful for circumstances where inotify does not work correctly, such as on file systems which do not support it.
You can now create Keter bundles without any applications. These can contain static hosts and redirects.