Hosting Overview


In a typical Relay environment, the items in purple need to be provided by you:


You don't have to have an enterprise system or third-party system. But if you did have them, this is how they would connect.

Minimum Requirements

There are some requirements for your workflow server, as described below.


You need to host the workflow server that runs your workflow: the code that you write on top of the Relay SDK. This is where your workflow logic runs. You can get your workflow server hosted externally with a service like Heroku, AWS EC2, Cloudflare, your own data center, etc.


Your workflow server must be reachable on the Internet from the Relay server. If your server is behind a firewall, then you need a way to expose it. A tool like ngrok may help you do that during development. The SDK already provides a built-in implementation of a websocket server. The Relay server will be the websocket client which upon a trigger initiates a connection to your websocket server on the workflow server.


Your workflow server needs to have TLS (a server certificate) for the Relay server to connect to it via a websocket. And this needs to be with a proper certificate authority, not a self-signed certificate. This is because the Relay server is enforcing that all traffic between it and your workflow server be encrypted. When registering your workflow on the CLI with the relay workflow create command, the URI of your workflow server must use the wss protocol (WebSocket Secure). The unencrypted ws protocol isn't allowed. Some hosting providers, such as Heroku and ngrok have TLS built in, but others such as EC2 may require some additional configuration. Some of the Relay SDKs may have support for TLS directly in their websocket server implementation. If you don't already have a TLS server certificate, Let's Encrypt may help you do that relatively easily and at no cost.

That's all. Beyond that, we recommend that you consult with your organization's I/T staff for processes and best practices required by your organization.

You are in control

Some of the benefits of this design are:

  • Your workflow code is never shared with Relay. There isn't anything to deploy to the Relay server, except a registration that points to your workflow server and describes the triggers you want to subscribe to. The Relay server communicates to your workflow server using a fixed set of primitives that are surfaced to you as methods and callbacks via the SDK.
  • Credentials used to connect to any of your enterprise / backend systems are never shared with Relay. You keep your credentials and data private to you, Relay never needs to access it.
  • Whatever data you do send to Relay is done via methods and webhooks you invoke, so it is all explicit.
  • You can host your workflow server wherever you want, with whatever processes you want, as long as it is reachable and has TLS.

Editing Workflows

As you edit the source code for one of your workflows, don't forget to save your edits to the file. And if your workflow app was running before your edit, Ctrl-C to exit your workflow app and restart it so the updated source code is read from the file. And if you are editing on a different machine than where it is deployed, make sure you transfer all affected files to the deployment environment before exiting and restarting your workflow app.

In the following pages we'll share some tips and tricks we learned from some of the common hosting providers, to help you get you up and running quickly. We aren't recommending any specific providers.