The Only Platform Built Specifically for Phoenix
Deploy Phoenix applications with git push.
Run on a platform designed for the BEAM.
Native clustering, direct Postgres connections, and persistent processes come standard.
Most platforms treat Phoenix like a stateless PHP or Node.js app, wrapping it in a Docker container that isolates it from the world.
This breaks the distributed capabilities that make Elixir powerful.
Gigalixir was built from the ground up to support the Erlang VM.
We expose the networking primitives required for distributed Erlang so your application behaves exactly as the core team intended.
Phoenix is not a stateless request/response framework.
It manages long-lived WebSocket connections through LiveView and relies on OTP patterns like GenServers and Agents for in-memory state.
Platforms that aggressively sleep "idle" apps or force restarts disrupt these patterns. Gigalixir respects the lifecycle of your processes.
Each LiveView mount is a process on the server. As long as the instance is running, that process holds its assigns and state.
Because we do not "sleep" instances (even on the free tier), your LiveView connections remain stable, and your users don't experience arbitrary disconnects.
If your application uses GenServers for caching, rate limiting, or session tracking, those processes keep running.
We do not kill background processes to save resources.
Your supervision tree remains stable, allowing you to build stateful systems without relying heavily on external caches like Redis.
When you deploy a new release, Gigalixir rolls it out without dropping existing connections immediately.
We spin up the new version, wait for health checks to pass, and then shift traffic. This ensures that users on active sessions are transitioned gracefully.
Other platforms route database traffic through connection poolers like PgBouncer, which breaks default Ecto behavior.
We provide a direct network path to your PostgreSQL database.
This means you don't have to disable features or write workarounds just to get your database code to run.
The Questions We Get The Most at Gigalixir Support
Yes.
LiveView requires persistent WebSocket connections and server-side process state.
Because Gigalixir runs your instances continuously without auto-stop or suspension, LiveView connections remain stable and your processes retain their assigns between user interactions.
No. Gigalixir uses Cloud Native Buildpacks that detect your Phoenix project automatically.
There is no Dockerfile to maintain and no container image to build locally.
We read your elixir_buildpack.config or .tool-versions to install the correct Erlang and Elixir versions.
Platforms that use PgBouncer for connection pooling break several PostgreSQL features that Ecto relies on.
Named prepared statements fail in transaction mode, and advisory locks (used for safe migrations) are often dropped.
Gigalixir provides direct PostgreSQL connections, so these features work without configuration changes.
Gigalixir runs on Kubernetes and pre-sets the environment variables that libcluster needs. You simply add the Cluster.Strategy.
Kubernetes strategy to your application's supervision tree.
No manual peer configuration or mesh networking setup is required.
Run gigalixir ps:migrate from the CLI.
This executes your migrations against your production database using the secure internal network.
There is no need for a separate direct database URL or an SSH tunnel.
Reach out directly to the Engineers who built Gigalixir to discuss your specific architecture, integration challenges, or compliance constraints here 👇
Stop fighting generic cloud infrastructure.
Whether you’re working with Elixir, Python, or Node.js, get the specialized support and performance your application deserves.