Technology Stack

The software and systems we use to build @dwyl.

Contents [click to expand]

Technology Stack
Why?
What?
tl;dr
Recommended Reading

Why?

As a team of people using technology to make digital products,
it's essential to be unambiguous about the stack/tools we use,
so that everyone is clear what we all need to master.

If anything is unclear or you have any questions please ask.
We are always happy to answer tech stack related questions.
Please make sure you read the whole doc first.

What?

This document + diagrams describe the full PETAL Technology Stack we use for dwyl products/projects.

Each element in our stack was carefully selected based on its individual merits.
When assembled into a seamless machine, the stack is unrivaled for developer effectiveness and world-class reliability!

The `PETAL` Stack

PETAL is an acronym for the following elements:

Phoenix - the Web App framework that organizes routes, schemas, controllers and tests logically.
Elixir - the functional fault-tolerant programming language that is a joy to work with.
Tailwind - the interface library for building beautiful mobile-first & responsive web apps that feel fast and are easy to extend. With hundreds of templates & examples.
Alpine.js - the tiny effects and enhancements JavaScript library that loads fast and progressively enhances the user experience. This is 100% optional, apps work fine without it.
LiveView - the system that significantly simplifies creating interfaces that update in real-time whenever a change is made by anyone else.

Let's go through each of these in a bit more detail.

`Phoenix` 🐦‍🔥

Phoenix is the Web Application Framework that does not compromise.

Phoenix is the successor to the incredibly popular Ruby-on-Rails framework (commonly referred to as Rails). That was used by many startups and successful companies e.g: AirBnB, GitHub, Shopify and Twitter (most of which have migrated away from Rails for scalability reasons).

Phoenix was built from scratch by highly experienced engineers who worked on/with Rails.
It solves all of the speed/socket/scaling/concurrency issues people felt when building/using Rails apps. The list of benefits Phoenix has over (virtually every) other Web Frameworks is extensive.
See: dwyl/learn-phoenix-framework#our-top-10-reasons-why-phoenix

`Phoenix` the "Most Loved" Framework ❤️

Phoenix tops the list of "Most Loved" Frameworks for the 3^rd year in a row
on the 2025 StackOverflow Developer Survey. ❤️

https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-web-frameworks-and-technologies

This is not a popularity contest; the votes are private/confidential. When software engineering community collectively votes that a framework is their "most loved", you know that they love using it.

`Elixir` 💧

Elixir is the functional programming language used by the Phoenix framework.
Elixir is a beautiful language written from scratch to be friendly, concise and efficient. What this means is that you can write elegant expressive programs that achieve impressive results with fewer words. And because it's functional (with immutable data), it's considerably easier to follow the logic even when reading someone else's code or your own you're returning to after a few years.

Yes, Elixir not as "mainstream" as JavaScript, Java, C# or Python, but the adoption is growing rapidly and most importantly many experienced engineers are gravitating towards and describing it as their "most wanted" Also a language's popularity has more to do with the intellectual inertia people/companies have because they allow existing (legacy) codebases to dictate future development; i.e. sunk cost bias. see: dwyl/learn-elixir#key-advantages

`Elixir` Remains Most Loved Language

For the 3^rd year running, Elixir is the 3^rd "Most Loved" programming language in the world: survey.stackoverflow.co/2025/technology/#2-programming-scripting

First appeared on: https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages

This is a good measure of how much people enjoy working in the language. And as we all know people who enjoy their work are better at doing it!

Note: The 2026 StackOverflow Survey will be released later this year, we will update this repo accordingly.

`Tailwind CSS` 😍

Tailwind is the most sane way of creating a beautiful web app UI that can easily be extended by a team of people without fear of one person's change "breaking" another feature. Unlike "traditional" CSS which - as it's name implies - encourages "cascading" of styles, Tailwind makes the style of each component specific and local to that component. see: dwyl/learn-tailwind

We paid for a license for Tailwind Plus: tailwindcss.com/plus It has hundreds of carefully crafted UI templates that can easily be customized.

`Alpine.js` (Optional) ✨

Alpine.js is a lightweight library for enhancing interactions in a web application.
It's declarative, responsive and easy to learn.

Alphine.js plays well with LiveView for progressive enhancements. see: dwyl/learn-alpine.js

alpine.min.js @ 3.13.8 is 41 Kb uncompressed. When delivered over a network (minified + gzipped), the size footprint drops down to roughly 14 KB.

This means it loads in under 200ms (1/5 second) even on a slower 3G connection.

For a concrete example of how we are using Alpine.js, read: app.js it handles the drag-and-drop and effects in the MVP. This is fully documented in: /drag-and-drop.md

`LiveView` 🚀

LiveView is a radically simplified way of building realtime web apps with significantly less code.

Phoenix + LiveView allows us to build rich interactive web apps with realtime reactive UI (no page refresh when data updates) without writing JavaScript! This enables building incredible interactive experiences in less time and with considerably less code.

For more detail, on the "Why? What? How?" of LiveView, please see: dwyl/phoenix-liveview-counter-tutorial#liveview

Note: We only use LiveView where appropriate to the desired UI/UX; it's not a shiny object we must use everywhere. If live updates are not needed e.g: in Auth or Payment flows we use server-side rendered controllers with bare minimum client-side validation.

Beginner Tutorials? 🔰

We have crafted a "Complete Beginner's Guide" for each element in the stack, so that we:

Document our collective learning while we are building projects.
(because as humans we forget fast unless we capture it immediately!)
Share our knowledge with other people so we can:

Help to train (potential) new team members as quickly/effectively as possible.
Collectively iterate on our knowledge and "level-up" as a team!
"Onboard" the client team (who may want/need) to support/maintain the codebase/project if/when we seamlessly "hand over".
Inform the wider community of both technical and non-technical people ("stake holders") who are generally interested in understanding the project.
Enlighten other teams/organizations/agencies/etc. we aren't in direct contact with that there is a "more fun" way of building software!

Make everyone's life easier/better by having a "launch pad" for rapid learning!

We have written several beginner tutorials that span our technology stack and tools we actively use in development.

`Phoenix` / `Elixir` 📝

A few of our learning repositories specific to Phoenix and Phoenix Liveview.

Learn Elixir: dwyl/learn-elixir
Learn Phoenix: dwyl/learn-phoenix-framework
Counter (LiveView): dwyl/phoenix-liveview-counter-tutorial
Chat (Phoenix + Channels): dwyl/phoenix-chat-example
Todo List (LiveView): dwyl/phoenix-liveview-todo-list-tutorial
Stopwatch (LiveView): dwyl/phoenix-liveview-stopwatch
Chat (LiveView): dwyl/phoenix-liveview-chat-example
Realtime cursor tracking (LiveView): dwyl/phoenix-liveview-realtime-cursor-tracking-tutorial
Papertrail and Phoenix: dwyl/phoenix-papertrail-demo
Flutter and Phoenix: dwyl/flutter-phoenix-channels-demo

Small Apps That Showcase `Phoenix` 💡

We have a couple of "internal" (but Open Source) projects that use Phoenix and serve as a good showcase for the stack:

Hits: dwyl/hits 📈
Image Uploads: dwyl/imgup 🖼️
Labels: dwyl/labels 🏷️

`Elixir` Utilities 🔪

Along our journey building apps for clients and ourselves, we've created a few reusable packages:

fields: dwyl/fields - field definitions with validation and transparent encryption/decryption.
useful: dwyl/useful - utility library.
content: dwyl/content - content negotiation.
link: dwyl/link - parse, shorten and format links.
auth_plug: dwyl/auth_plug - seamlessly add authentication to any Phoenix App.

All the code we write is extensively documented, comprehensively tested and regularly maintained (where required). One of the many beauties of Elixir code is that it requires very low maintenance; it just keeps working year after year.

`Flutter` 📱

We are using Flutter for our Native Mobile App. See: /flutter.md

Along the way we've created several learning resources for Flutter and how to use it with other technologies:

Learn Flutter: dwyl/learn-flutter
Learn Dart: dwyl/learn-dart
Counter: dwyl/flutter-counter-example
Stopwatch: dwyl/flutter-stopwatch-tutorial
Todo list: dwyl/flutter-todo-list-tutorial
Bloc: dwyl/flutter-bloc-tutorial
Supabase and Flutter: dwyl/supabase-flutter-demo

Miscellaneous 💳

In this section, we will list a few repos that explain concepts and tools that we are actively using while developing our app.

Payment processing: dwyl/learn-payment-processing
API design: dwyl/learn-api-design
Test-driven development dwyl/learn-tdd
Insomnia API client: dwyl/learn-insomnia
Github Pages deployment: dwyl/learn-github-pages

Our `MVP` 💡

We have built a working MVP version of our App! Check it out at dwyl/mvp! 📱

Database? 🗄️

The reason we do not specify our Database in the PETAL acronym is that Phoenix abstracts its' database access via Ecto to provide built-in support to the following databases:

PostgreSQL (via postgrex)
MySQL (via myxql)
MSSQL (via tds)
ETS (via etso)
SQLite3 (via ecto_sqlite3)

By abstracting the data layer using Ecto the application is "decoupled" from the database.
This means that if a client asks us to deploy to MySQL or Microsoft SQL Server
(e.g. because they already have in-house capability for maintaining one of these databases)
we can easily accommodate that without re-writing any of the Phoenix app! Changing a couple of lines of configuration is all that is needed.

We Prefer `PostgreSQL` 🫶

Our "standard" (preferred) DB @dwyl is Postgres. see: dwyl/learn-postgresql 🐘
Postgres is the most "mature" Open Source Relational Database. It's 100% Free (including all "advanced" features) and has been deployed and battle-tested in every environment from AWS to "Bare Metal" and Google Cloud to Microsoft Azure!

Many well-known/successful apps rely on Postgres as their main database.
NOT that you should adopt a particular technology based on who else is using it,
but it's good to know that plenty of teams are getting excellent results with Postgres!

See: List of Organizations Using PostgreSQL

We have used most of the "popular" Relational Databases. e.g: MySQL, Microsoft SQL Server, Oracle and Aurora, etc; all RDBMS have their pros/cons.
The reason we like/use Postgres is because the community is superb.
There is a great "bank" of answered questions on StackOverflow and new questions get answered fast.

From 2023 to 2025 Postgres has remained the most used and most desired Database: survey.stackoverflow.co/2025/technology#2-databases 46.5% of respondants use Postgres more than double MySQL (20.5%).

Operating System? 🧠

A "traditional" LAMP stack includes the Linux Operating System in the name.
The "PETAL" stack runs on any (desktop/server) Operating System
and can be deployed to any "cloud" infrastructure provider.

While we have a strong preference for Unix (e.g. OpenBSD) or Linux (e.g. Ubuntu or CentOS) we know that
both Phoenix and Postgres run on almost any environment including Microsoft Windows Desktop & Server. We typically deploy our Phoenix Apps using Ubuntu + Docker.

Continuous Integration ✅

We are using GitHub actions for Continuous Integration & Deployment/Delivery.
It's free/included with GitHub and easily meets our needs.

For an example of this, including automatic deployment to Fly.io see: .github/workflows/ci.yml

We have used other continuous integration platforms in the past and at the request of clients, e.g: GitLab, Travis-CI, Circle-CI or self-hosted Jenkins. We can easily adapt to the needs of the project.

Deployment 🚀

We make a point of deploying our work as soon as there is something worth showing to the target audience of "end users" so that we can get feedback as early as possible.

Lately we have been using Fly.io for deploying our Apps. The experience is superb. ❤️

We have used every major Cloud infrastructure provider over the last nearly 2 decades starting with AWS in 2009. Over the years we have captured much of our knowledge public repos e.g: dwyl/learn-devops and dwyl/learn-aws-lambda

Many people have found our notes helpful.

Application Server 🏢

The Phoenix Application Server is hosted on (a minimum of) Two Servers.
(often many more which send messages one another to distribute load as a cluster).
The "cluster" is managed by Erlang's "Supervisor". The Erlang Supervisor is the "Gold Standard" in infrastructure management, having been used by Telecoms companies for over 20 years in production with some Telcos reporting 99.9999999% ("nine nines") of "up-time".

It's far more likely that the infrastructure provider (e.g. AWS/Azure) will have a fault in their network/datacenter than an Erlang server "crashing". An individual request/process may crash but never the whole server.

SSL/TLS Encryption 🔐

All communication is over secure/encrypted channel (by default at all times)
to protect the data/privacy of people using the applications we make.

We recommend using the Let's Encrypt service for SSL Certificates it's 100% Free (and provided by a Non-Profit foundation)
to help you get started, we wrote a step-by-step setup guide for apps deployed to any infrastructure: /letsencrypt-wildcard-certificate.md

tl;dr

There is no shortage of options available for Technology Stack! See: google.com/search?q=technology+stack
So, how did we arrive at the conclusion that PETAL was "the one" for us...?
We already had a really good Node.js Stack which worked well for us and our clients. so . . .

Why Try a "New Stack"?

Why Try Something New When We're Already Good with the "Old"...?

Our reasoning for considering an alternative approach/stack for building web apps was fueled by our curiousity and "shoshin".

"The important thing is not to stop questioning.
Curiosity has its own reason for existence."
~ Albert Einstein

In November 2016 we (once again) questioned our assumptions, re-examined and surveyed the "landscape" of "emerging trends" in web app development. We were ~~pleasantly surprised~~ delighted to see the amazing progress made by the people in the Elixir / Phoenix community! Please see: dwyl/learn-phoenix-framework#questions

Making Difficult Decisions

One of the most "difficult decisions" you will make in your "career" is which technologies and tools you will use to deliver the desired solution/benefit to the "end users".

Most people have the Tech/Tools decision made for them by the company/organization/boss they work for (e.g: Java -> Spring, Ruby -> Rails or PHP -> WordPress or Laravel, etc.) This is because most companies already have an existing app in "production", which you have been hired to extend.

Occasionally you will get the chance to build an app from "scratch"
however most of the time someone else (the "Architect") will make the decision for what "stack" to use on your behalf, so you will still be stuck with someone else's choices. If you are incredibly lucky the "Architect(s)" will have done their homework: surveyed the latest industry trends and investigated the "new and promising" technologies e.g: Stack Overflow "Most Wanted" list.

Most "Application Architects" Pick One Of These 3 Options:

Stick with what you (already) know, use existing stack with a minor variation because it's "easy to deploy" with the existing infrastructure and will not get questioned by the "Executives", DevOps team or "Compliance" department. This is the easy choice and nobody ever got "fired" for sticking with what they know "works".
Buy the whizz-bang all-in-one solution sold to them by the "Consultant" from "Big Vendor XYZ"; this can feel like a safe option, but it results in vendor lock-in.
Be Bold and try "Popular Framework XYZ" and hire an external team to build the new magic app. Then attempt to "up-skill" the internal team to maintain the code written by the consultants.

None of these choices is optimal, all have different levels of risk/reward. The "hardest" choice to make is the one where you try something totally different. The reality is that very few people have the time/resources/mindset/inclination to take a step back and open their minds to the idea that there might be a "better tool" for the job than the one they are currently using.

Toast Knife Analogy 🔪

Imagine Want to Make Yourself Some Toast.
The "user story" for this would be:

As a peckish person
I want a slice of tasty toast
So that I can have some crunch for my brunch!

( let's assume that you bought a loaf of bread from a baker
to reduce the options for solutions for simplicity
i.e. not baking from scratch! )

The "traditional" way to "solve" the challenge of making toast:

Cut bread with bread knife
Put sliced bread in toaster
Turn on toaster for pre-determined amount of time
Wait patiently for toaster to make toast

But ... what if instead the "old" way we just described, someone invented a way to toast the bread while slicing it...?!

Simply by using the "New Tool" for the job - in this case the "Toast Knife" - you can simplify the process to a single step!
This is the power of being open to considering "New" Tools/Technologies!
Get the same result in fewer than half the "steps"!

Focussing on Long-term Benefits

The short-term cost of learning a new stack (programming language or framework) is time, We contend that the 1 week learning time (depending on the focus of learners) will pay for itself within 1 month (often sooner if the team is large/distributed because the structure offered by Phoenix means everyone working on the project has a disciplined approach to adding new features)

Contextualising Technology Adoption (Mini History Lesson)

In 1996 Nokia introduced the "Communicator" and was a incredible revolutionary innovation! Internet, Email and Fax in your Pocket!!

Nokia continued to dominate the mobile phone industry/market for the next decade producing the best-selling 5110 and 3310 some of us are old enough to remember!
But by being "ahead" Nokia was unable to see the "contender" coming "out of nowhere" to challenge their position.

In 2006 nobody was making/buying "smart" mobile phones with glass touch screens that ran "apps" ...
in January 2007 Steve Jobs introduced the iPhone and literally changed the industry!

The dominant/incumbent mobile phone maker Nokia had 49% market share in 2007 mocked Apple's lack of features, poor battery life and high price.
By 2013 Nokia had 3% Market Share (for new device sales) and was sold off "for parts" to Microsoft while Apple became the most valuable company in history!

Many people still buy "feature phones" (the polite name for a device that does not have any "smart" functionality!)
but few people can convincingly argue that the reason they don't have a smart phone is because they don't want one;
over 90% 16-24 year olds own a smart phone and that number is expected to reach 100% by 2025 ...
ask someone in their 20's if they would go "back" to using a non-smart phone and see what they say ... "No Way!!"
they laugh uncomfortably and admit that: "My Smartphone is my Life!"
We feel exactly the same about "old technology". Sure the "old way still works", but if you can inexpensively switch
to something demonstrably better in every aspect, why would you stick with the "feature phone" of web frameworks...?
It's like taking the Bus to work when there's a perfectly good teleporter right next to the bus stop!! Madness.

We are not suggesting that everyone is going to suddenly flock to the "PETAL" stack the way people adopted smart phones. This is merely an illustration that when a technology has a specific/measurable advantage to it's users the adoption can be fast.

In the case of programming languages or application frameworks, moving one framework to another is a much more difficult decision.

But one thing is for sure we are going to use the "smart phone" even if other people insist on using the "brick".

Does it Scale?

The good news is that Phoenix "scales" really well!
see: phoenixframework.org/blog/the-road-to-2-million-websocket-connections

This post was published in 2015 and was one of the catlysts that made us pay attention to Elixir and Phoenix. We had been building apps with Node.js (what we refer to as our "legacy stack") since 2009 and deployment/scalability was always a chore. Seeing that a single Phoenix server could handle 2 Million Concurrent Connections was an eye-opener that made us immediately try Elixir.

Highly recommend watching Joe Armstrong's talk for a balanced primer on scalability: "Systems that run forever self-heal and scale": youtu.be/cNICGEwmXLU

Yes, scalability and especially fault tolerance is important. And Phoenix has your back with all of the above. It lets you focus on User Experience and rest assured that scalability is baked-in.

If you are new to building web apps, please focus on UX and forget about "scale"!

Focus all of your energy on crafting beautifully functional UI/UX that gives the person using your App their desired outcome in as few steps as possible.

The sad reality is that most startups fail before they achieve product-market fit. Of those that "make it", most will end up re-building their App(s) as they refine the UX over time.

So focus on moving fast and building well-tested features.

Unless you work somewhere that already has millions of users (e.g. Big Tech) and your team cannot consider anything that does not support a million concurrent connections ...
Most people have imaginary scaling issues not real ones.
discussing "scalability" before you have 100K paying customers is a waste of time!!

Stop wasting your time worrying about "scalability" and instead focus on building the useful features that people are requesting.

Forget about "scaling" until you have made something people want and are paying for to solve their immediate pain!
Once you have a few thousand paying "users", use the pile of cash you got from your product to hire experienced engineers to make it available to more people!

What About Full Stack `JavaScript`?

We still think that "Full Stack JavaScript" is a compelling proposition especially for people who are just starting out! It allows you to write one programming language on both the client and server; we get it! However we have learned from years of experience that it requires a lot more code and maintenance than PETAL for an inferior result in terms of UX/performance and developer productivity.

Alternative Databases?

If we were to consider an alternative to SQL, we would use RethinkDB: rethinkdb.com
But we are relieved that the Phoenix team is focussed on Postgres because that eliminates
the "ambiguity" or "discussion" of "which database" to use! Postgres is a fantastic "general purpose"
db that has a rich ("structured") query language that lets you JOIN data!!
Also, now that Citus DB is fully Open Source we know that Postgres can easily handle billions of writes per day. See: citusdata.com

Radical Simplicity

“If it takes an hour to figure out what’s going on, well,
that’s an hour that wasn’t spent doing something else more useful and interesting."
~ Rachel Kroll

Please read: https://www.radicalsimpli.city
In the site/manifesto Stephan makes the case that Apps have gotten far too complex:

Note: the "Complexity 2021" is just the year when complex Single Page Apps (SPAs) reached the fever pitch Many people were using the React hammer to build slow-loading apps with complex architectures. Thankfully, many people/teams have realized that it's a poor UX and moved away from it now.

He advocates for a return to basics:

No need for microservices message queues or other complex tech that is only relevant to 0.1% of mega scale companies:

We agree.

If by some luck our product reaches the point where we need mega scale (millions of people creating billions of items) we know that our chosen stack will scale just fine.

Before then the complexity will only slow us down and reduce the chances of success.

Other Tech/Tools?

We have written extensively about our choice of programming language in: learn-elixir#102.

Our use of Elixir is for a very specific reason: we are building fault-tolerant realtime systems. For the type of App we are building, Erlang/OTP is the undisputed king on the server side.

We could use almost any other language/framework, but it would be a lot more work for an inferior result.

If we need to build a specific feature requested by a person using our product/service, then we will 100% consider a technology that enables us to deliver it.

How to Propose `NEW` Tech/Tools?

The way to propose a specific tech/tool is simple: open an issue describe how the tech/tool will help us build a specific feature that has been requested by a person using our product.

Proactively create a new repo in the dwyl org to capture your own learning of the tech/tool you are proposing. e.g: dwyl?q=learn

Once you have invested the time to learn the tech/tool beyond "hello world" and are confident that it will help us achieve a specific end-goal, then please make the case for it.

Name		Name	Last commit message	Last commit date
Latest commit History 102 Commits
legacy		legacy
.gitignore		.gitignore
CONTRIBUTING.md		CONTRIBUTING.md
README.md		README.md
flutter.md		flutter.md

Uh oh!

Folders and files

Latest commit

History

Repository files navigation

Technology Stack

Why?

What?

The PETAL Stack

Phoenix 🐦‍🔥

Phoenix the "Most Loved" Framework ❤️

Elixir 💧

Elixir Remains Most Loved Language

Tailwind CSS 😍

Alpine.js (Optional) ✨

LiveView 🚀

Beginner Tutorials? 🔰

Phoenix / Elixir 📝

Small Apps That Showcase Phoenix 💡

Elixir Utilities 🔪

Flutter 📱

Miscellaneous 💳

Our MVP 💡

Database? 🗄️

We Prefer PostgreSQL 🫶

Operating System? 🧠

Continuous Integration ✅

Deployment 🚀

Application Server 🏢

SSL/TLS Encryption 🔐

tl;dr

Why Try a "New Stack"?

Why Try Something New When We're Already Good with the "Old"...?

Making Difficult Decisions

Most "Application Architects" Pick One Of These 3 Options:

Toast Knife Analogy 🔪

Focussing on Long-term Benefits

Further Reading on Long-term Thinking

Contextualising Technology Adoption (Mini History Lesson)

Does it Scale?

What About Full Stack JavaScript?

Alternative Databases?

Radical Simplicity

Other Tech/Tools?

How to Propose NEW Tech/Tools?

Recommended Reading

About

Resources

Contributing

Stars

Watchers

Forks

Releases

Packages

Used by

Contributors

Languages