What Versions of Phoenix do you Support?
What versions of Elixir and OTP do you support?
All versions of Elixir and OTP.
Some buildpacks don’t have the bleeding edge versions so those might not work, but they will eventually.
Can I have Multiple Custom Domains?
Yes! Just follow How to Set Up a Custom Domain for each domain.
Do you Support non-Elixir Apps?
Yes, we support any language that has a buildpack, but hot upgrades, Remote Observer, etc probably won’t work.
Built-in buildpacks include:
For details, see https://github.com/gliderlabs/herokuish/tree/v0.3.36/buildpacks
If the buildpack you need is not built-in, you can specify the buildpack(s) you want by listing them in a
For an example, see How to Deploy a Ruby app.
What is Elixir? What is Phoenix?
How is Gigalixir different from Heroku and Deis Workflow?
For a feature comparison table between Gigalixir and Heroku see, Gigalixir vs Heroku Feature Comparison..
Heroku is a really great platform and much of Gigalixir was designed based on their excellent twelve-factor methodology.
Heroku and Gigalixir are similar in that they both try to make deployment and operations as simple as possible.
Elixir applications, however, aren’t very much like most other apps today written in Ruby, Python, Java, etc. Elixir apps are distributed, highly-available, hot-upgradeable, and often use lots of concurrent long-lived connections. Gigalixir made many fundamental design choices that ensure all these things are possible.
For example, Heroku restarts your app every 24 hours regardless of if it is healthy or not. Elixir apps are designed to be long-lived and many use in-memory state so restarting every 24 hours sort of kills that.
Heroku also limits the number of concurrent connections you can have. It also has limits to how long these connections can live. Heroku isolates each instance of your app so they cannot communicate with each other, which prevents node clustering.
Heroku also restricts SSH access to your containers which makes it impossible to do hot upgrades, remote consoles, Remote Observers, production tracing, and a bunch of other things. The list goes on, but suffice it to say, running an Elixir app on Heroku forces you to give up a lot of the features that drew you to Elixir in the first place.
Deis Workflow is also really great platform and is very similar to Heroku, except you run it your own infrastructure. Because Deis is open source and runs on Kubernetes, you could make modifications to support node clustering and Remote Observer, but they won’t work out of the box and hot upgrades would require some fundamental changes to the way Deis was designed to work. Even so, you’d still have to spend a lot of time solving problems that Gigalixir has already figured out for you.
I thought you weren’t supposed to SSH into Docker containers!?
There are a lot of reasons not to SSH into your docker containers, but it is a tradeoff that doesn’t fit that well with Elixir apps.
We need to allow SSH in order to connect a Remote Observer to a production node, drop into a Remote Console, and do hot upgrades. If you don’t need any of these features, then you probably don’t need and probably shouldn’t SSH into your containers, but it is available should you want to.
Just keep in mind that full SSH access to your containers means you have almost complete freedom to do whatever you want including shoot yourself in the foot. Any manual changes you make during an SSH session will also be wiped out if the container restarts itself so use SSH with care.
Why do you download the slug on startup instead of including the slug in the Docker image?
Great question! The short answer is that after a hot-upgrade, if the container restarts, you end up reverting back to the slug included in the container. By downloading the slug on startup, we can always be sure to pull the most current slug even after a hot upgrade.
This sort of flies in the face of a lot of advice about how to use Docker, but it is a tradeoff we felt was necessary in order to support hot upgrades in a containerized environment. The non-immutability of the containers can cause problems, but over time we’ve ironed them out and feel that there is no longer much downside to this approach.
All the headaches that came as a result of this decision are our responsibility to address and shouldn’t affect you as a customer. In other words, you reap the benefits while we pay the cost, which is one of the ways we provide value.
How do I add Worker Processes?
Heroku and others allow you to specify different types of processes under a single app such as workers that pull work from a queue.
With Elixir, that is rarely needed since you can spawn asynchronous tasks within your application itself. Elixir and OTP provide all the tools you need to do this type of stuff among others. For more information, see Background Jobs in Phoenix.
If you really need to run an Redis-backed queue to process jobs, take a look at Exq, but consider whether you really need Exq.
My git push was Rejected
Try force pushing with
git push -f gigalixir
What happens when an app exceeds the memory limit, even briefly?
When you go over the memory limit on a replica, your pod will get OOMKilled and restarted.
Alhtough not instantaneous, the timing is pretty close to it.
What happens when an app exceeds the memory limit for a sustained period of time?
Alhtough not instantaneous, When you go over the memory limit on a replica, your pod will get OOMKilled and restarted.
This will continue until the memory limit is increased for your service.
What happens if an app exceed our CPU limit, even briefly?
CPU cycles are throttled, so should not see your application shutdown directly related to CPU usage. What you will experience is that your app will get slower.
What happens if an app exceeds the CPU limit for a sustained period of time?
CPU cycles are throttled, your app will stay in a slower state for the duration of the exceeded limit.
When we go over our Limits, can we Trigger Alerts/Notifications to our Team?
The errors would show up as an OOMKilled status, which shows up in the logs, allowing you to trigger alerts and notifications.
What Happens when an App Scales Down - Graceful Shutdown?
When scaling down apps (which includes during deploy, the scale down of the old version), a replica is sent the SIGTERM signal.
If your application stops accepting new requests (more below) at this point, then this results in your replica being removed from the load balancer. This means that new requests will not route to the scaling down app. However, any requests that are already on that replica still need to handled by that replica and completed before the next event (SIGKILL).
Then we wait 30 seconds for your app to shutdown. If after 30 seconds, it hasn’t shut down, it is sent SIGKILL and terminated.
If your application doesn’t stop accepting new requests, then you have a race condition for requests around that SIGKILL. This means that you could drop requests. Additionally if you take longer than 30 seconds to respond to requests, then you can also drop requests.
You can test your applications response to this by running a deploy and running requests during the deployment while watching the
gigalixir ps command. If the new pod shows HEALTHY status, and your old pod is still responding to requests, then your app is still responding to requests after the SIGTERM.
This article https://ellispritchard.medium.com/graceful-shutdown-on-kubernetes-with-signals-erlang-otp-20-a22325e8ae98 elaborates the situation and gives some advice on how to gracefully shutdown the pod.
Why was my Account with a Disposible Email Removed from Gigalixir?
We do not allow disposable email accounts in our system. Any email address flagged as being a disposable email account will be removed.
We do not sell email addresses. In return, we ask that our customers have a valid email address so we can reach you in case there is information about your account/applications that needs to be discussed.