Writing Your Application

Choosing how your code is built

All builds on Stratum are done using Buildpacks. Each buildpack has its own conditions for autodetection - make sure that your application’s file structure allows this to happen.

Sometimes, the wrong buildpack can be chosen if multiple buildpacks’ conditions are met. For example, having both a package.json and a requirements.txt in the root of your repository would match both the Node.js and python buildpacks, and the result might not be the correct one. If this occurs, you can pin the correct buildpack. Note, also, that you can create a custom buildpack if needed.

Choosing how your application is run

Stratum uses a special file named Procfile (no extension) to designate what commands to run to start your application. A Procfile consists of one or more lines, structured like this:

<target>: <command>

For the main application for your code service, the target is always web. For workers, the target can be named differently - “worker” is typical, but it’s up to you.

For a simple python application, your Procfile might look like this:

web: python

For a python application with a worker named “myworker”, it might look like this:

web: python
myworker: python

Binding to PORT

In order to expose your application to the Service Proxy, and thus accessible the outside world, it needs to bind to a very specific port, stored in the environment variable named PORT. If this port is not bound to, your application will continue to run, but it will not be accessible.

Note: Do not change the value for PORT, or hard code that value in your application. While rare, it is subject to change.

Database and Cache Connection Strings

The strings needed to connect your application to any databases and caches in your environment are made available in variables to that code service, created when those services are provisioned. The names are based on the name of the service - for example, if your environment has a PostgreSQL database service named “database-1” and a Redis cache named “cache-1”, the corresponding connection strings are likely stored in variables named DATABASE_1_URL and CACHE_1_URL, respectively.

Some clients require these strings to be in different forms than provided, and some clients only take the parameters separately. Feel free to create additional variables as needed to make this easier - it’s your environment.

Filesystem Structure and Storage

Applications and any build artifacts are always placed at /app inside each container. This means that, for example, a file named in the root of your repository will be located at /app/ inside your code service’s container(s).

Your application has total read/write access on the local filesystem. If temp space is needed for uploads, /tmp is a good choice. Note, however, that any local filesystem changes are lost on redeploy, and local filesystem changes are not visible from one job to another. For more information and solutions, see the Cloud Storage article.

Cloud computing for healthcare

If you store, process, or transmit Protected Health Information, rely on Catalyze to keep you HIPAA compliant with our platform as a service, mobile backend, or managed HL7 integrations.

Contact Us Learn More

Catalyze learning resources

Learn the important and intracate details of HIPAA compliance, make use of HL7, and understand the security aspects of handling protected health information with our learning resources.

Visit Catalyze Learning Resources