Deploying Julia

Mark Halonen
Apr 17 · 3 min read
Julia: A fresh approach to technical computing

You’ve got something running in Julia that’s pretty neat. It glues together some crazy-good libraries like DifferentialEquations and creates a cool output you want to share with the world.

You want normal humans to be able to try out your code from the convenience of a website. So begins your adventure in deploying Julia.

Websites are written in HTML and JavaScript. So you need your Julia functions to be available behind an API that can be called from JavaScript.

I’ll cut to the chase and tell you what we ended up using for, and then go over some things that failed.

The website is written in React and hosted on the excellent Netlify service. Simple enough.

The API is running on a web server in Julia running on an ec2 instance in Amazon. It took a bit for us to arrive at this solution.

Both the website and the API are served from kosher HTTPS setups. Google Chrome has basically declared war against plain old HTTP, and you don’t want your users to see scary warnings.

What Didn’t Work is just an interface to some Julia functions. Why pay to have a server running all the time? AWS Lambda to the rescue! Except lambda doesn’t have Julia support. No big deal, compile Julia to an executable and call it from Python. Only problem being that the saunasim compiled executable was like 500MB, way over the limit of 50MB for lambda. Also, spinning up a new Julia runtime for each usage is not where Julia excels, as it uses JIT compiling. It was taking 17 seconds to run the first simulation, and then subsequent simulations were nearly instant.

We can’t have our users waiting 17 seconds, the Julia runtime needs to be running continuously so we can get instant results.

So AWS Lambda is out, what about Heroku? Heroku is a great service that lets you deploy a Docker container and automatically makes your endpoints available behind an HTTPS URL. Given other projects (such as DiffEqOnline) had success deploying non-trivial Julia services, this looked really promising. We could deploy with one command and get a free and simple HTTPS endpoint. Except we couldn’t get our Julia project to launch under the Heroku 500MB and 60 second limits. After a few days of toiling with trying to get Julia to launch under these constraints, we gave up. We tried many Julia precompilation things, and even tried compiling to an executable. We just kept hitting roadblocks.

Another fast, free, and simple solution was, which worked great for a quick demo, but is not really meant to be a long-running solution.

Buckle Down

I knew AWS ec2 could do it. It’s just lower level than Heroku, and requires more manual steps. So I embarked on building the HTTPS API endpoint in ec2, knowing I’d at least make linear progress.

It turned out that all our effort with Heroku was not wasted, as we had Dockerfiles we could use to deploy on ec2. I created an ec2 instance and got the saunasim server running. It’s available behind HTTP, victory! But we need HTTPS, nothing less.

So a Google search for “HTTPS to ec2” yields a couple answers that are non-trivial, and show why Heroku exists.

In a nutshell, if you use the AWS loadbalancer, they’ll manage your HTTPS certificate for you. So we set up AWS loadbalancing (which “balances” the load to our single ec2 server), and ta-da! We had our Julia API functions available under a legit HTTPS endpoint.

So, our website is served at

and the api is under


We’re running on a single t3.medium ec2 instance, which costs $30/month.

Mark Halonen

Written by

Software Developer

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade