Are you using Phoenix in production for public facing traffic? Let's hear your story! If you want to get interviewed (email based or a podcast) come on in

I’m very interested in hearing about how you’re using Phoenix in production.

Anyone is welcome to share their story. That means anyone from a solo developer who just deployed their first side project with Phoenix to large companies running Phoenix for years while serving billions of page views a month.

The goal of hearing these stories would be to raise confidence that people are successfully using Phoenix in production. It would be really beneficial for others to know these details because we’re all on the same team here. We all want to build really nice web applications quickly and in a reliable way.

Currently there’s not too many blog posts or talks going into detail on this topic. A lot of companies say they are using Elixir but when it comes to serving customer facing traffic with Phoenix I have not found many examples or details.

So to help fix that problem, I just released a podcast / interview site at to talk about running a Phoenix driven app (or technically any app) in production.

The podcast episodes will be audio only (no video) but if you’re not comfortable doing an audio recording together, interviews can also be done over email on whatever schedule works best for you (it’ll be a low stress environment where you can take as much time as you want on answering).

If you’re interested in sharing your story, please fill out 1 of the 2 different Google forms below:

Podcast (audio only)


As for the site itself, there’s not too many interviews posted yet because the site went live less than 24 hours ago. I have not mentioned the site to anyone other than posting it in this thread. To be more useful for readers I figured I would wait until there’s a couple of interviews and podcast episodes before announcing it publicly.

Once there’s a few posts I’ll announce it to my existing audience. I’ve been running a technical blog for ~5 years on my personal site.

If you’re curious, the first interview on the new site covers how I run and host my blog. It’s to help serve as an example of what to expect in the text interviews. You can view that here:


P.S., If you want to see these interviews, drop a reply here too, just to gauge interest. It will help convince larger companies that this is something more than 1 person wants to see happen.


If you really need some things of phoenix being used in production, we’ve been using it in production for years, though I’m unsure if I’m allowed to mention the specific place I work but it is a college, so I’m unsure how much of an interesting interview it would be. We’ve been using it in production for ~3 years though.


If you need to see Elixir being used out in the wild, check out our #community:showcase-adoption section and there might also be some of interest in our Blog Posts: Evangelising Elixir thread :smiley:

There’s also maintained by @doomspork @gemantzu @tajchumber :023:


Do you mean with public facing that there is nothing before it like Nginx? If not, then I can answer questions about Code::Stats. But it’s a hobby project of mine, not work stuff. We can do email or you can hop on our Discord channel to just chat. :slight_smile: My way of deploying is relatively old school though, at least compared to the cool kids. :smiley:

1 Like

I’m sure it would be interesting in either case, but for a confidence boost it would be very beneficial to be able to mention the real site. Do you have someone you can talk to at your uni to see if it would be ok to mention the school?

nginx or any type of proxy / load balancer is fine. I meant public facing as in you have a Phoenix app that’s serving traffic from people on the internet (which it sounds like you do).

Personally I think a smaller scale deployment still has a lot of value because it gives perspective on what to expect at that point. Old school is also good because most people aren’t using Kubernetes at scale with multi-region, multi-planet, multi-dimension auto-fail over.

Shoot me an email and we’ll set something up.

closing in on ~2 years - with straight up phoenix (umbrella even) deployed on heroku - (where the legacy rails app - and most importantly the DB lives) - no issues.

serving an api to mobile app(react native) - and a react spa admin interface(migrating soon to liveview I hope.)

couldn’t be happier.


There is always They have a GitHub repo with all of the source code.

Here’s an idea… Since they do podcasts and interviews, maybe they would be willing to do a “role reversal” and allow you to be a guest on a podcast and interview them about I would reach out to them. I’m sure they’d be willing to talk about it with you.

Oh, and don’t forget, there is our own which also has a GitHub repo


Yep. I’ve been on the changelog podcast as a guest where the discussion was pretty focused on Phoenix and them open sourcing their platform, but it was a “backstage” episode recorded on a whim so it covers a ton of other things too.

I was going to reach out to the author of the site for sure, but wanted to test the waters with other potential sites first since changelog is pretty well known for being open source and open about running Phoenix. It’s one of the first sites you would find on a Google search on this topic.


I have no doubt they’d say No. ^.^;

Only a tiny sliver is accessible from the Internet, most requires being on the local LAN/WiFi, and there is a lot of HiPPA around it (big nursing program here) so a bit of extra paranoia is around it. So far it’s passed every test ran across it though by the testing contractors. ^.^

1 Like

I really don’t understand the concern here. The small startup I’m at has been using Phoenix for a customer-facing website for almost 3 years now. Started at version 1.1 and have migrated to 1.4.6 currently. We have a pair of clustered EC2 instances, deployed via edeliver/distillery and 80+% of our deploys are hot deploys. Yeah, we’ve had occasional growing pains, but overall the technical excellence of the stack is worth it. But I don’t have time for interviews.


I personally don’t have a real-world Elixir/Phoenix deployment, but in the spirit of this thread, because I like the question, I’ll share a little research that I did. First, Google migrate ruby elixir. Some results:

Phoenix has been a joy to use for the projects we have worked on and because it’s the de facto standard in the Elixir community, I’m confident that any code we have written is maintainable by anyone else with Phoenix experience. … I have zero regrets in adopting elixir for our client work and my personal projects.
If anything I wish I could go back in time and tell my 2012-self to “drop” Node.js sooner! I regret trying to use a spoon to dig a swimming pool; pick the “right” tool and let the BEAM do the work!!

there were some limitations that have stopped us from fully implementing the backend part of app in Phoenix. Phoenix and Elixir were still rather new to us and we didn’t have sufficient experience with deploying Phoenix on such a scale. As the client insisted on delivering an MVP as soon as possible, we simply didn’t have the time to spend on polishing our Elixir and Phoenix skills. … All of us have agreed that the integration went smoother than expected. We feel we did our best to make the product capable of handling even the heaviest traffic, especially given the fact we were very short on time and it was our first Phoenix app on such a scale. … We are happy to say we have experienced very little bugs and issues in the course of development and we learned a lot. And most importantly, at least from my personal perspective, I fell in love with Elixir and feel that this is just the beginning of many great adventures!

So i’m sure there will be many more transition patterns that are useful in migrating a Rails app but so far I’ve found the process not only pretty painless but also feels vastly superior. Not to mention just how much faster the Elixir app is; response times under 100ms bring joy to the heart.


I’ve been using Elixir at a hobby level since 2013 and on a production level since 2015. We (dscout) have ran Elixir in some form as our primary API since mid 2016, and before that we used it for websocket based services.

We run four languages in production (Elixir, Ruby, Python and JS) and have steadily been moving all web facing endpoints and background jobs from Ruby/Rails to Elixir. I hesitate to say we are using Phoenix because it is largely Absinthe, Ecto and job processing.

Overall it has been a tremendous win for us in terms of speed and processing ability. We are all in.


I have a very small Phoenix app in production. It’s a slackbot It’s been running for a half year. I’m not sure about being an interview material, but I can share my experiences.

Deployment: was a pain in the … But after learning it, I quickly came to enjoy it.

Productivity: could be much higher if I used it on a daily basis. Still very very productive.

Maintenance: I didn’t do much in the product after I deployed it and I’ve just come back to work on it more. Can’t praise enough how easy it is for me to read my old code and edit it.

Ecosystem: Not on the same level of maturity as Ruby libs unfortunately, but the libs I need are in a good shape. + It’s very easy to edit whatever you need, because function programming makes it really easy to understand someone else’s code. Comparing it to Ruby, I’m afraid forking unmaintained Ruby code :face_with_hand_over_mouth:

Development: Love docs, love code that is easy to modify and read, speed - tests/autoreload/compilation, love that there is a separate frontend directory with webpack. In Rails there is a Webpacker - another abstraction. :man_facepalming:

Upgrading deps/elixir/phoenix - Simple.

I’m even using a single GenServer(OTP) in my codebase, which is a perfect solution for my problem - simple and reliable.

Because it’s a slackbot my code is mostly based on webhooks. Pattern maching, functional programming made it very simple to handle any kind of event from webhooks. The whole code is super easy to trace and modify if anything changes (event schema or business logic).

In my opinion, if you have a team of Ruby developers, you can pretty easily move to Elixir and be blown away by it’s toolset and ecosystem. Very very modernish take on programming.

As a matter of fact, most of my side projects are being built in Elixir, because it’s a pure joy (from business and dev point of view).

I do agree that it’s still pretty niche language, where you can get a feeling that it’s the best for realtime, low latency, big codebase projects. But from my experience, it’s even a valid choice for smaller projects that may not need all that “fancy stuff” like OTP. A very simple example is a code reload function during development time. It’s super fast (response time) and it works very well, therefore you can just maintain long time focus easily.


Thanks for replying everyone. I haven’t forgotten about this thread.

I’m coming up with a big list of questions to ask and will be reaching out to everyone who wants to be interviewed in the upcoming week (and then we can individually figure out dates that works for both of us).

1 Like

I’ve found this interview with Dave Lucia very interesting: Among other things he spoke how he helped build to have SPA-like experience with server-side HTML with Phoenix serving millions of requests on 2 Heroku dynos without needing CDN in front. (I assume they still used CDN for assets etc, but not for content it seems like!)


Nice find. What’s cool about that interview is they talked briefly about creating a process for each visitor of the site so they could track things like “did they see this post already?”. While it doesn’t seem like they are using LV, that idea of having a process lingering around and storing state for each connected user is similar to what LV would be doing.

Tbh, this idea of having a process with a little bit of state for each client is a fairly standard idea for actor systems. It’s how Phoenix Channels work:

Unlike stateless HTTP connections, Channels support long-lived connections, each backed by a lightweight BEAM process, working in parallel and maintaining its own state.

A team I was in once also designed a transactional API based on starting a ‘parent transaction’ actor and sending it ‘child transaction’ messages which it would aggregate and then write to DB.

Anyway, actor system-oriented design is a big topic so my talking too much about that would derail this thread :slight_smile:

Let me help with the derail: you guys at the OCaml community should really invent an actor model concurrency library! :wink:

1 Like

Wait for multi-core and algebraic effects to (finally) land and it will be simple. ^.^

Just chiming in here. I’ve a site where I store links for myself. Think Pinboard, but using Phoenix and Elixir,

There are a few wrinkles compared to some other deployments mentioned here.

  1. I use Moebius as my data access library rather than Ecto. No real reason other than I wanted to feel less like developing a Ruby on Rails app, though I am realizing that using Ecto isn’t the same as using ActiveRecord.
  2. I deploy by:
    a) Using a Docker container locally to build a tarball release
    b) scp-ing that tarball to the server, unpacking it and placing the release in a directory
    c) Running a simple bin/<app name> start to get it going.

I love this deployment process because I didn’t have to install Elixir on my prod server and things still work great.

I’ve a few other things, like a link crawler that I’m still developing, but the site is super stable and uses 1/2 the memory of a Rails app and even less than a Sinatra app I was previously using for the site.