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.
I’ll cut to the chase and tell you what we ended up using for saunasim.com, 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
saunasim.com 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 https://ngrok.com/, which worked great for a quick demo, but is not really meant to be a long-running solution.
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.