We're sitting down with Eric Matthews, the educator, author, and developer behind Django Simple Deploy.
If you've ever struggled with taking the final step of getting your Django app onto a live server without spending days wrestling with DevOps complexities, then give Django Simple Deploy a look.
Eric shares how Django Simple Deploy automates away the boilerplate parts of deployment so you can focus on building features instead of deciphering endless configs.
We'll talk about the new project's journey to 1.0, the range of hosting platforms it supports, and why it's not just for beginners.
This is Talk Python to Me, episode 500, recorded February 20th, 2025.
Are you ready for your host, please?
You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy. Follow me on Mastodon where I'm @mkennedy and follow the podcast using @talkpython, both accounts over at fosstodon.org and keep up with the show and listen to over nine years of episodes at talkpython.fm. If you want to be part of our live episodes, you can find the live streams over on YouTube. Subscribe to our YouTube channel over at talkpython.fm/youtube and get notified about upcoming shows. This episode is sponsored by worth recruiting worth recruiting specializes in placing senior level python developers and data scientists let worth help you find your next python opportunity at talkpython.fm/worth Eric welcome back to talk python great to have you here nice to see you again michael nice to see you as well last time we talked about your book right and now your project your deployment project i love talking about deployment because i think it's such an enabling technology or enabling skill and your project Django Simple Deploy is certainly in that realm.
Yes, I have appreciated your comments about deployment over the years.
Thanks. Well, they're a hard one. My skills in deployment are a hard one.
I kind of want to talk a little bit about the journey for people, but not yet.
Let's get a quick introduction of who is Eric. What do you do?
What's new in your life since the last time you were on the show?
Oh, gosh, yeah. It's all context for this project because this project ties together a lot of the different things that I've done.
Short version, I grew up in New Hampshire, moved to New York City, then moved to Alaska.
Just last year, I moved to Western North Carolina.
And I had a background in science. I studied physics in college and got pulled into teaching.
spent a long time teaching math and science, fifth grade through twelfth grade, which was super fun because it's not at the level of undergrad or grad work, but the questions young people ask always make things interesting. And I got pulled into programming because I always did it on the side. And I kind of felt like, I always felt like at some point, I might focus more on programming and less on classroom teaching. So for the past five, six years I've been a full-time writer and programmer.
It's been enjoyable. Yeah. And congrats on the move. You really like to sample different weather systems, different environments.
You're going to get a different summer experience in North Carolina than you might in Alaska. I know it gets warm somewhat there, but
it's warm a
lot in North Carolina.
Yeah. We're in the mountains, so we can have cool nights at least.
Yeah. Lovely. My brother lives there and I think North Carolina is a really neat place.
It is, yes.
Yeah, yeah, yeah. So let's talk about this going from science to teaching to programming just a little bit, because I did a very similar journey. I think mine was accelerated in terms of its time frame, but I was in grad school. I studied math and then taught math, calculus, linear algebra, those kinds of things at universities at GTA, and then kind of got into programming as part of it. And then I'm like, wow, this is really fun. How do I, how do I do more of this? You know what I mean? And after evaluating it, just academia didn't seem like a thing I really wanted to try to chase. And so I basically, I took one or two programming classes, but otherwise, other than that, I taught myself programming a number of years ago. That is kind of scary. Last century, let's say. And I don't know, I feel totally confident about it these days, but at first it was, you know, do I belong here?
All these things
seem hard. What am I doing wrong? Should I have gotten a CS degree? I don't think any of those things are true. I think just, you know, as I learned hanging out with CS people, it was hard for them too. Like it's, but maybe talk a little bit about your journey, right? Because I'm sure it would be helpful to other people. There's many people out there who are doing something somewhat similar.
Yeah. Questions about academia kind of steered me this way as well. I studied physics in undergrad because I started as a chemical engineer because I had a great chemistry class in high school. But I found that engineering classes felt like being taught how to solve other people's problems. And my favorite class as an undergrad or as a freshman was physics because it was the only class that really seemed about truly trying to understand the world. And I love that. So that's what led me to focus on physics. And I was going to be a particle physicist, but I did not want to
be...
Wanted to spend some time at sun
or maybe outside of
Chicago or wherever. Yeah. Okay.
Yeah. And I, yeah, when I was really young, I heard about atom smashers. I thought somebody like literally had hammers where they smash atoms.
So every stage,
yes, every stage I learned more about it was more and more fascinating, but I didn't want to be a student forever. And so I want to do something outside of being a student before pursuing the graduate work that would get to get me to be a part of a physicist.
So when I was looking what to do, I had been a tutor in undergrad, and I tutored calculus and physics.
And I tutored those classes because I watched classmates start to hate math and physics because of how they were taught.
And that's the only reason people hated those topics.
And it was really humbling because I was 18, 19 years old and tutoring people in their 30s and 40s who were doing mid-career changes.
Speak of the field, like you maybe don't necessarily belong there telling someone how to do something.
But at the same time, you probably knew it really well, right?
Yeah.
And I felt like I belonged, but it was really humbling as far as just sorting out like school systems and where to go.
So anyway, that led me into teaching.
And I thought I would just teach for a couple of years and go back to science.
But I found that the challenge of reaching everybody in the classroom was as hard and as satisfying as hard science.
And so I just love teaching.
I love what it brings up for other people.
And, yeah, it's always stayed interesting.
For me, the transition into more of a focus on programming was my father died.
I've told this story a few times over the years about the origin of the book Python Crash Course.
But my father died in 2011.
And my mom asked.
He was a programmer.
That's how I first learned to program.
My mom asked me to go through his computer and she found all these, or she asked me to go through his computer to see if there was anything worth keeping.
And there wasn't, but for me, it was a really personal experience of seeing all these projects he had started.
They would never get finished.
And I realized that I had a bunch of those programming projects as well.
And so that kind of was a turning point for me to get me out of the practice of just building a bunch of side projects and start to focus on one or two real world projects that other people would benefit from.
That's a great story.
That's certainly one of the challenges of you can build a project and you can get it to run, but you're maybe halfway there, getting it out to the world in a real world sort of way.
You've got all these challenges of, I need to pick a place to run my app.
Wait a minute, databases?
Why are these migrations so hard?
How do I
do migrations?
I got the first one up and now I can't change it.
just breaks it doesn't run anymore and you know there's just all these these aspects not even taking into account the stuff you got to add to go from a toy project to making it real logging error handling etc etc right yeah
i mean this is all a good segue into the topic of today i mean django simple deployed to kind of put it out there for people who haven't heard of it um it's a um package that automates deployment uh django deployments so if your project runs locally on your computer and you get to the point where you want to make it public for other people to use if you haven't already gone through the deployment process for most people that's a cliff and they kind of just fall off i spend all this time learning django all the time building this private they really care about solves the problem does it better than other people's work because you know it's new and whatnot and then they go to deploy it and they find that they have to spend so much time reading a platform's documentation um tweaking their settings um adding this file file and then kind of crossing your fingers and hoping that it works.
Every time I've gone through that process, I've kind of thought to myself, this is all just boilerplate.
Like we're just being told to, everybody's being told to add the same settings, make the same modifications.
And so I had that shower
thought of like, automation.
Yeah.
I had that shower thought of like, okay, how could we do this configuration from the Django side?
So
when we're just looking
at the user's computer, you've got a project that's working We know it works.
How can we do all the configuration automatically so that you then just push your automatically, correctly configured project to your hosting platform?
So Jango Simple Deploy does that.
You pip install on Jango Simple Deploy.
You need to have a plugin for the platform that you're using.
So Fly.io is a go-to example.
And then you add Jango Simple Deploy to installed apps.
And then there's two modes for this project to work.
The fully automated mode is easier to talk about because you run one command, bifimanage.py deploy --automate all.
And if you do that and you have that platform CLI installed, it configures your project, makes a git commit, and pushes your project, and your project appears in a new browser window, which feels like magic.
That's kind of magical, actually.
Yeah, yeah.
All right.
So I want to talk about what platforms are supported.
But before we do, maybe we could talk more broadly about just hosting platforms that you've considered, that you see out there, that people publish Django apps to, right?
On one hand, we've got really, really straightforward platforms.
On the other, you can get as complicated as you want, basically.
You play the game of how many AWS services could you combine into one Django app, which, you know, that's kind of like the obfuscated code contest.
How much can you fit under one line that's unlegible but still does the thing or whatever, right?
You know, we started this with a conversation about our backgrounds.
And so kind of weaving this for a little bit back into that background story, I do remember one of my transitions to doing more professional programming work was when I was teaching, I would write programs to address inefficiencies and difficulties we had in our school for our staff.
And so I remember like exactly this, getting something that like automated report card generation for our staff.
And I got it working on my computer.
So like for me, writing report cards was so much easier than for everybody else.
And so I learned Django.
I'm like, cool, I can share this with everybody else.
And I tried to deploy it and it just, I could not do it.
It just fell
apart.
And I sort of figured it out.
So my first deployment platform was a laptop in a closet in my school connected directly to the school network.
So the deployment worked for people on our network, and it was only out of the kindness of our IT staff that would allow me to do that.
Clearly not a solution for most people.
It's really hard to deploy. Let me just deploy my machine to the school.
Yes,
yes. Update.
Let me
go to that closet.
Yeah, yeah, yeah.
I'm going to be in here for a few
hours. I'm programming on the server.
Yeah.
So, okay, Heroku is the first one to talk about because Heroku was one of the first platforms that really automated a lot of the DevOps work and allowed us the classic sales pitch for Heroku was run and get push Heroku main and your project is live.
There's always a bit more to it than that, including that configuration to make your project work on Heroku.
So the platforms I start thinking about are the ones that manage the DevOps aspect for you.
Heroku, Flyto.io, Platform.sh, Python Anywhere is in there.
So to take a step back even further, this project started because I used Heroku for a while.
In Python Crash Course, the first edition, I taught people, I walked people through deploying a Django project to Heroku.
is the only part of the book that felt like I'm not really teaching anything.
I'm just telling people to write certain things and add certain
files.
A bit of explanation about what it does, but mostly it's, you know, make these changes and cross your fingers that you type them all right.
So I wrote a Heroku build pack that did the configuration automatically, but it did it on Heroku servers.
So you'd specify this build pack.
It would load that build pack onto Heroku servers, and then all your configuration changes would happen on their end.
Tell us what is a build pack.
I'm not sure that I can tell you.
It's basically, I said my short
take is...
I'll tell you, I've never built a build pack myself, and I've deployed a lot of Python, so...
Yeah,
my short description is it's a set of programs, body of code that configures your project for running on that specific platform.
Got it, okay.
And so typically it's generic and it's not targeting, it's not trying to do any changes to your project.
We won't go further.
I'll say something
wrong.
Yeah, yeah, yeah, sounds good.
But the takeaway for that is it felt like doing Heroku's work for them.
And so it was nice for anybody trying to push Django to Heroku, but that boundary of like, what's our work?
What's their work?
Are we doing work free for them?
That's an interesting question.
And it really felt like it was skewed towards doing their work.
Right.
Well, I've done it once or twice, deployed an app to Heroku, never for real work, but to, you know, play around with it and sort of check it out.
Because Heroku was definitely a darling of
the
Python space and certainly of the Python tutorials, right?
Because for a long time, they had a free tier.
And so everybody
who needed to deploy something was like, here's how you put it on Heroku to sort of complete the loop and get it out there in the world, right?
Right. And then, yeah, you know, a testament to Heroku is how long it has worked without a lot of attention from them. And so they lost a lot of trust in the community, not just from doing away with their free tier. It's really hard to maintain a free tier. It's just puts a big target on the platform for abuse.
But it's about some reliability issues and communication issues around issues on the platform.
So there was an exodus from Heroku for a while.
And I was working on this automation problem for a while.
And I had that shower thought of like, okay, all that work that I'm doing through the Buildpack on Heroku's end could be done through a management command with NJNGO.
You can do all the changes to your project on your computer if you know what to do.
So internally, Django simple deploy is just a single management command, that deploy command.
And when you run that command, based on the plugin that you have installed, it knows which platform you're targeting.
And then basically, I've just spent hours pouring over the documentation for a few different platforms.
And so we pick up the platform that you're trying to deploy to, make all the changes necessary for a basic initial deployment to that platform.
And then there's two ways you can push your project.
The fully automated mode puts all those changes into a single commit, runs that platform's deploy command, and pops up your project in a new window.
Yeah, and the transport mechanism is Git, right?
Good question.
Not necessarily.
The transport mechanism is whatever that platform uses.
So for Fly, Django simple deploy makes the configuration changes for your project.
and then it calls the fly deploy command.
So I don't even have to know what fly deploy is using behind the scenes.
You have the CLI installed, simple deploy calls that deploy command.
For Heroku, when it gets to that deployment stage, in the automated mode, Jingo simple deploy runs git push Heroku main.
And so it's one of the nice things about this project, and part of the reason it has taken so long to get to 1.0 is quite adaptable to different approaches.
Yeah, that's pretty wild because you're just automating the CLI for that platform, right?
Right.
And Chris is commenting, there should be one obvious way to deploy your Django project to a service.
Yeah, he's right.
The nice thing about this is Django Simple Deploy becomes this abstraction layer between your work and the platform.
So it creates a nice, consistent interface for deploying to a wide range of platforms.
And when a platform inevitably changes their deployment process or configuration requirements, as long as one person makes that update to the Django SEP deploy plugin, everybody else gets to just keep using that consistent interface for how you do your initial deployment,
which is really,
really nice.
Yeah, it is really nice.
You don't
have to worry about all the details and also the ability to move without losing all of your expertise.
This portion of Talk Python to Me is brought to you by Worth Recruiting.
Are you tired of applying for jobs and never hearing back?
Have you been getting the runaround or having trouble making it past the AI resume screeners that act as the new gatekeepers for your next level Python job?
You should reach out to Worth Recruiting.
Worth Recruiting specializes in placing senior level Python developers and data scientists.
They work directly with hiring managers at startups, helping them grow their software engineering and data science teams.
With Worth, it's not just connecting you with the company.
It will guide you through the interview process and help make sure you're ready with their detailed preparation approach.
They can even coach you on salary negotiations and other important decision-making processes.
So if you're ready to see what new opportunities are out there for you, reach out to Worth Recruiting.
Let them be your partner and specialist to find the right Python developer or data scientist position for you.
Fill out their short contact form at talkpython.fm/worth.
It only takes a minute.
That's talkpython.fm/worth.
The link is in your podcast player's show notes.
Thank you to Worth Recruiting for supporting the show.
This is where it gets really fun to talk about this project because, you know, people think when people first hear about this project, they think it's just for beginners.
It's just for people who already know deployment.
But where is I going with that?
Oh, so thinking about writers, authors, myself first, but content creators, tutorial writers, presenters.
If you're wanting to include deployment as part of your process that you're teaching people, then a lot of people have chosen not to do that because as soon as you include deployment, you're now tied to that platform's stability.
As soon as they change their process, you've got to update your materials or it's broken.
and that's not appealing.
So for somebody who uses Django Simply Deploy in their tutorial, again, as long as one of us keeps the plugin updated to work on that platform, your learning resources stays the same.
That is really nice.
And whether
you're
teaching a college class or you're just writing something for your blog, it is really nice.
Yeah, and I think about the Django Girls workshops.
And so part of that, the goal of that conclusion of deploying your project is just to see a live.
Like, why are we doing this if we can't see a line?
You don't necessarily want to spend a whole bunch of time focused on deployment.
And so if you can kind of really crunch that into like, okay, we're going to run these commands.
We have a working deployment.
It's not about hiding deployment from people.
Because one of the coolest parts of this project is that it contains all those configuration changes in a single Git commit.
Is there a verbose mode where you get to show all the little steps it's doing and stuff?
Yeah, it is verbose by default.
So you get to basically it streams and dumps all the platform's output as it's deploying, which is kind of important because if you don't do that, you just see this blank screen for two, three, seven
minutes.
Yeah, it's just sitting there spinning.
Yeah.
But to slow this down, take a step back for a minute.
I've mentioned the automated mode where you include this stash-tash automate all.
That's easiest to talk about because it boils down this deployment process to three steps.
I don't actually recommend that for most people because it makes a Git commit for you, runs a deploy command, and maybe you want to have a little more control about that process.
There's a configuration-only mode, which is every bit as helpful, but it lets you kind of take a little more control.
And so what you do for most platforms, you have to create a resource, basically a deployed project, an empty project on that platform, and then you run deploy.
And Django Simple Deploy recognizes the resource you just created on that platform, configures your project, and then it stops.
And so you now have a configured project, and you can run git diff, and you get to see all the configuration
changes
that were made on your behalf.
So you don't have to just trust it.
Yeah, yeah.
So when I shared this on the Django Discord yesterday, somebody was excited about it, and then I said something about that commit that was made.
And they said, oh, it makes commits for you.
I'm not sure I want to use that.
Is it okay?
You can do the longer mode where you get to review that.
And then you can see all the files that were created for that platform.
You can see the settings changes that were made to make your project work.
And then you can choose to make that commit.
You can choose to push it or revert it.
Even if you use the automated mode, it's still all the configuration is one commit.
And so you can just revert that commit and you're right back to your project.
I'll throw one more piece in there right away.
one of the priorities of the project is that it does not change the local behavior of your project.
And so when I run the test suite, it tests that all the configuration changes are correct for the target platform, but it also runs run server again locally and makes sure that we haven't impacted the local running of your project.
Oh, interesting. It'll run it to make sure it basically starts. Nice.
Yeah, you know, this automated versus config sort of deal, it reminds me a little bit of how maybe DBAs feel about ORMs.
You know, like they're like, oh, you can't just let it run arbitrary queries against my database.
Like, how do we know it's doing the right thing?
I'm sure you feel that way for a while.
But eventually, all right, we've reviewed them.
They're fine, right?
So maybe this config thing you do a couple of times, you're like,
yeah, that's
what I would do anyway.
Just run it, right?
Because what
else are you going to do?
You're probably going to create a script that does the things you expect it to do anyway for yourself as a bash script or something, right?
And so might as well be a Python script.
Yeah.
I mean, it's funny hearing you talk about this because this project started as a pile of bash scripts.
And so,
yeah.
I got a pile of bash scripts on my server.
They do things.
Yeah.
One of the pre-1.0 tasks was a long issue that was just about converting all these shell scripts to Python.
And mostly that was about creating, making this work cross-platform.
So it's basically taken me like four years to get this to 1.0.
And it's that 80-20 principle turned into like 595 principle.
So another reason, so a good thing to kind of move into, another reason it took so long to get to 1.0 was originally this was all one library.
So it was just Django simple deploy.
And originally you would run managed.py deploy --platform by.io.
And so the entire project contained all the code for all the different platforms.
And that felt better than the original project just targeting Heroku because you have choice.
But it felt like a nightmare for maintenance.
Anytime any project changes, it's going to need an update and it's just going to grow exponentially.
Yeah, it becomes combinatorially complex in
terms of dependencies, which
is not a good order of magnitude.
It's not good.
Yeah.
So I had some people kind of very kindheartedly nudging me towards just doing a 1.0 release to get over that fear of a 1.0 release.
But it was always about having – I had a vision that the mature version of this project should be plug-in based.
So the core project, Django Simple Deploy, is small.
It's platform agnostic.
All it does is inspect your project, inspect your system, and then hand out the rest of the work to a plugin.
And so currently there's a plugin targeting apply.io, plugin for platform.sh, platform for Heroku.
I have a proof of concept plugin for CodeRed, and I'm working on a proof of concept for DigitalOcean.
Yeah, so many cool things to talk about with this.
Yeah,
yeah.
Before we go, I do want to maybe just go through some of these hosts and let you talk about maybe why they're included.
Which ones are, there's stuff out there, obviously, that's not included.
Why is it not included?
So Heroku, obvious, especially when you started, when they had the free tier and stuff like that.
I kind of want to get them, I know people are angry at them.
I understand that.
But also, I kind of want to give them a little bit of a pass, like offering free hosting to the world where people just put up malware and other badness and use the trust of your domain to sort of leverage that, it's challenging.
And I don't know.
I understand people are frustrated with them, but that's tough.
So Heroku, platform as a service, you push your stuff up, you say, here's my code, here's how you start it, run it for me, please.
There's not a lot of Linux.
There's not a lot of shell, right?
They kind of take care of that for you, yes?
They do.
And there's still, yeah.
I've had conversations with people who, with founders of a number of these platforms over the years, because it's always interesting to talk about this.
And platforms would love to see an easier way to deploy Jango projects.
One of those founders said something really insightful at one point, and I appreciated the honesty, is that we're all trying to be second best for beginners.
Because if you draw that crowd, you're drawing more support than benefit in the short term.
And so, yeah, for a long time, Foroku paid that cost.
they were willing to be the go-to for everybody.
So there's still a lot of projects running long-term on Heroku.
I know some important Python ones that are there.
Yeah.
Okay.
And then we got fly.io and platform.sh.
What's the story of these?
Honestly, I haven't used either of them.
I've heard of them.
I haven't used them.
So the selling point for fly.io is they're an edge-based platform.
And so
they take your,
if I'm saying this right, They take your project and they push your application code to a bunch of different nodes.
And so your code
is...
Kind of like a CDN, right?
Yeah, CDN for your application code.
And so your
code is right
close to your end users.
And so I don't need it, but they've built it well enough that I can just push a project there and it works.
And I'm a big fan of, you know, if your project does what you need it to, is it a good question?
Is it good enough?
And so it's been good enough for me for a lot.
And I know it's targeting some more complex use cases.
I
have so many questions.
It's so interesting.
Well, the first thing that comes to mind is what about databases, right?
If your app is running, yeah, you've got to have some way to correlate and centralize and make the currency of the database and all that work, yeah.
They've had some fantastic people working for them, and they have some fantastic blog posts.
So they've done really interesting cutting-edge work around distributed SQLite.
databases. And so, yeah, they are quite familiar with that question and they
have answered
it well and they are answering it well.
If you can answer that question well, then you can get some stuff that flies, you know? I mean, I guess, hence the name. I didn't even do that on purpose.
I've been using bunny.net, which is a really nice CDN platform, but just for static content, not for application code that talks to the database.
And I understand how you would replicate the database, but the challenge is if you have chatty rights, all of a sudden you're pushing your database away from your app, which has its own sort of latency and stuff.
But what an interesting idea.
Okay, and Platform.sh?
Platform.sh started as a PHP, I believe, started as a PHP-only platform, but then expanded to support other languages.
And so they have been sponsors of DjangoCon for a long time.
And I really enjoy working with their platform.
Deployment is pretty straightforward.
And then, you know, one of the things I look for in these platform as a service is, so once you push it, I'm very happy to have them managing the DevOps work.
I also want to be able to like get into the server and run commands and see what's going on.
And so they make it easy to do that.
Yeah, if things are not starting or they're crashing or something, sometimes just go, just 30 seconds at a glance at the log file or something.
Oh, yeah, or maybe why is that file?
That file is actually missing.
Oh, that's weird.
Let me see if I can just get that.
And then you're back to like, okay, back to platform as a service, and you're good, you know?
Yeah, and that's, you know, platform as a service certainly works for people who know nothing about, you know, hopping into a server and running commands.
But they're also for, like, people who know how to do that and don't want to do that.
And so a service like platform.sh that makes it easy to do both is also, I see it as an onboarding for people who have something worth deploying, don't know DevOps yet, but letting them hop in and start to do that is pretty interesting.
Yeah, it's very interesting.
Okay, so I can run Python manage.py deploy --automate all, and that will take my app and put it into whatever destination you pick, right, of those three.
For these platforms as a service, a lot of times you have to have a database.
Sometimes that's a managed Postgres or whatever you might have data that has to import initially.
You know, you're like, well, here's all the counties in the United States and we have to query them for stuff.
So we preload that at first.
How does all that get connected and happen, right?
If I had like no database and I just have a pure Django app that just runs Python, easy.
I see how this works, but there's settings and stuff here that vary by production versus dev.
Yeah, fun question.
So I've done most of the development work on Django Simple Deploy.
I've actually run sprints at several PyCons and several Django Cons.
And this project has brought together like 8 to 15 people at each sprint.
It draws some interest.
And so the project would not be where it is without those contributions.
A lot of those people have made some contributions and not done a whole lot outside of the conferences, but that whole group of people has been available to just bounce ideas off of.
And so a lot of the pre-1.0 work was also like me getting rid of all the baggage that just kind of only made sense to me, or you really need to have years of contact with the project to make sense of it.
And so now it's at a place where the structure is pretty consistent.
And so one of the things I'm looking forward to is somebody else who knows Fly.io managing the Fly.io plugin more than me.
And so they don't need to go deal with Chango Simple Deploy.
They can focus on the parts of the script that do the things you were just talking about.
So all the configuration has been largely my choice.
You know, okay, on Heroku, we'll choose this Postgres instance because it's cheaper, because it lets people get started.
It's possible for somebody to either take the Heroku plugin and add a few more CLI flags to give you a bit more choice, or just write your own Heroku plugin.
And so right now the plugin for Heroku is dsd-heroku.
Somebody else could do like DSD Heroku-large, and it's meant for scaling large or deploying large-scale Heroku projects.
And so that's not a, I don't want to do that work.
They should write their own.
That's if you have a use case that you know well, you want to automate.
Simple Deploy just becomes this, again, abstraction layer for, you know, you have a consistent interface for running that deployment from within Django.
Yeah, there's a nice plugin model, which really opens things up.
I suppose the short answer is probably, well, the Django ORM will create the database structure for you if you could just tell it where the database is, right?
Right.
And I know certain apps I've built, if they have data that has to be preloaded, I'll just have a little check like, hey, has this table got any data in it?
If not, run the load up the database the first time.
Otherwise, assume it's all good and keep going.
that pretty much handles it?
I think, you know, it's kind of two directions I'll take this.
You know, a short list of the projects I've done over the years, they tend to be smaller, but they tend to be impactful.
So one project, automated report cards for students.
I used to work with struggling students, students who were plenty smart, but life had happened and they had gotten off track with school.
And so they just had holes in their, in their graduation requirements.
And so those students wanted to graduate, but they didn't know where to focus their efforts.
And so looking at a transcript was really hard because it's just a bunch of letters and numbers.
So I wrote a program that automated a generation of visual transcripts.
So I'd read their text-based transcript and then give them basically a chart, a bunch of gauges.
You just look at it in 30 seconds, know which classes you needed to focus on.
And it also went from deficiencies to strengths.
So traditionally, we talked to students who are struggling and saying, you need to do this, you need to do that.
You could see where they needed to do their work, but you could also see where they had been shining.
You could see where the strengths were.
And so I wrote a project.
I worked with whale researchers.
And people don't know this.
Sperm whales have learned to pick the fish off of – I'll take a step back.
People catch halibut, fish for halibut by putting literally miles long cables on the ocean floor or lines with a hook every six to 10 feet.
And so you put a thousand hooks on the ocean floor, leave it overnight or pull it.
And that's how you catch halibut.
And sperm whales have learned to listen for the sound of the transmission changes when somebody puts their boat into gear to pull those hooks.
They swim towards that sound and they just pick the fish off those lines.
Wow.
And so these researchers were starting to put transponders on boats that would allow anybody who saw a sperm whale to report that.
And then you could kind of time your fishing sets to be away from the sperm whales.
And so I wrote a project that just like these researchers didn't know how to get their data from one place to another.
And so I just wrote a small Django project that listened for that data and gave them a visible place where they could go to it and share it.
And one other, oh, I lived in Southeast Alaska, and we were having increasing landslides, more frequent landslides, and more impactful.
And so I wrote a small project that examines real-time stream gauge data and turns that into a measure of landslide risk.
And they gave a talk about that last year at PyCon.
All those projects are small.
They're never going to scale to millions of users.
They all need a database.
And so they all fit this model of something like I personally would build.
And if I didn't know deployment, those would not have ended up being useful.
And so this tool takes all those people out there right now who are getting the skills to build something that works locally.
And they don't have to go through that three weeks to three months of learning how to deploy things.
So I appreciate you bringing up the questions of what happens with these larger scale projects.
But there's also a whole class before you even get there of projects that would make the world better if they could be easily deployed.
Such a challenge because if you go down the, there's so many paths that people get led down that are not good paths.
You know, it's sort of the architectural equivalent.
I guess even just the DevOps equivalent of you're not Microsoft, you're not Google, you're not Netflix.
You probably don't need the chaos monkey running around your whale research project.
Right, right.
But people read that and they're like, well, I saw a really awesome conference talk and people loved it about how they had like geo-replication of their database and stuff.
You're like,
yes.
Interesting.
not for you.
So the other direction that's interesting to finish out this discussion, so I'm targeting a VPS right now.
I have deployed a Django project to DigitalOcean just on the bare VPS.
For people less familiar with that virtual private server, it's basically a brand new virtual Linux machine that you can push your project to.
And so this is more complicated because rather than just like making a few configuration changes to your project and then running a platform's deploy command, you have to do that whole update the server, install Django, set up a Git push if you want to do that approach, make the right port changes and whatnot, expose that.
So it's more work for me to get that proof of concept done.
But once it's done, the work I'm doing to write a plugin for DigitalOcean would work just as well for Hetzner, just as well for Linode.
And then it opens up to all the different approaches that people take to deployment.
One of the interesting questions about Django Simple Deploy is what are the boundaries?
So what is simple?
And I don't know the answer to that yet.
It shouldn't become tube loaded.
It shouldn't re-implement the entire CLI for a platform.
But the bounds are pretty large.
So you could have a DigitalOcean that targets NGINX Benicorn.
You could have one that targets using the Doku approach.
You could have one that targets external databases.
There's really, it's a pretty open platform for automating deployment processes.
Yeah, absolutely.
Lots of people.
I mean, once you knock out one of those virtual servers, it's really, really close to seeing, well, anything that can run a Linux VM pretty much can do it.
And you were talking about Nginx.
You know, you might, I don't know, have you considered Caddy?
CaddyServer.com?
As I was saying Nginx, I was like, oh, wait, there's another one that I should be saying.
Well, I use Nginx for all of my stuff because it's gotten over the years, gotten more and more complicated.
However, you've got to run, you've got to independently manage Let's Encrypt, and there's this sort of scaling up process.
First, you've got to put the non-encrypted version up, so that cert bot and all the Let's Encrypt stuff can find it.
Then you create the SSL certificate.
Then you change the configuration again, because it won't run saying it's SSL until it actually has this, like there's this scaffolding step that's always messy.
And if I think like easy getting started for people, Caddy, which manages the security and all that and has a real simple configuration language, it seems like it might be a good option.
And it has 62,000 GitHub stars.
It's, I think a person or two uses it, you know?
That's kind of neat.
Yeah, last week, before I started the DigitalOcean plugin, I asked on Mastodon how people are deploying to VPS these days.
And Cady was one of the things that came up.
It was super interesting to see the range of approaches that people are using.
So, you know, as I go through this, I'm kind of asking the question for basic initial deployment for somebody new to this platform, what are some sane choices?
So Cady or Nginx, Postgres or SQLite.
So I'll make those choices.
And one of the open questions that I don't have clear answers to is, you know, where are the boundaries around those plugins?
So I'll certainly implement a --DB flag that lets you choose like Postgres or SQLite.
But I don't want to do a flag for like --approach, daku, whatnot.
At some point, it makes more sense to have other people write other plugins and just foster that plugin ecosystem.
so
another consideration and kim out in the audience was hinting at this before and it's certainly the way that i'm doing things these days is docker so let me just give you an example like yeah you can go all in and you could run on like the doc like eks and all these kinds of things you can go way way deep on it or you can just do stuff as simple as like hey i want i want the front end web server to be caddy i could install caddy on the server using apt or whatever but then you those kind of update more slowly, you have less control over it. You could just as equally well run a catty Docker image on that machine and have basically a zero touch experience on the server itself, other than just having a Docker thing there, right? And you can do whatever you want to that Docker image. You could even have a catty Django simple deployed one based off their original one or, you know, things like that where you've got it exactly configured. What's the story with Docker? And how have you been thinking about that? Because once you start to go to virtual or you start to get into some of these processes and some of these ideas?
Yeah, great question.
And it certainly has come up multiple times.
My main experience with Docker is working with Fly because Fly is a Docker-based approach.
I have not written my own Docker files, but I have learned about them.
And so short answer, Docker is an approach to deployment, and there's nothing stopping anybody from writing a plugin that has a Docker-based approach.
this kind of gets back to the question of like what's next
yeah
I'm going to finish the plugin for a proof of concept plugin for DigitalOcean I'll take it to the 1.0 version of that approach so people can reliably deploy to DigitalOcean with a particular articulated approach it'll probably be catty choice of SQLite or Progres Whereas, and then I'm probably like, my best approach is probably to back off of writing more plugins because I could spend the next few years just enjoyably exploring all these platforms and approaches.
But I really should back off, just continue to let people know the project exists, make sure these set of plugins that I've started continue to work, and then just continue to tighten up the internals so that it's easier and easier for other people to write plugins.
I can already tell from the way you're talking, like you could, I have a DSD plugin template repository.
It's in the Django Simple Deploy organization.
And so if you want to write a plugin, you don't start from scratch.
You download that repository for the DSD plugin template.
You don't clone it because there's no upstream for it.
Download it, install it alongside Simple Deploy in development mode, and you can run tests right away.
So you run an integration test and it just verifies it.
It gives you a couple of questions.
What's the name of your platform?
What's the command you want people to use?
Do you support automate all?
And then it writes a new plugin for you with all the plumbing there.
You run tests, verify that it works, and then you start writing your platform-specific code.
And so there's a bit of a learning curve for developers where you got to learn, like, what...
You know, Django's node deploy has a module called plugin utils.
And so that's how you write output in a way that's consistent with the rest of the project, feeds into its logging.
There's a run quick command for small changes you're making to the project.
There's a run slow command for things like deploy to make sure we're capturing output, streaming it, whatnot.
So you learn those utilities, but you pretty quickly get to a place where you're just focusing on your expertise or opinion about how to approach deployment for a particular platform.
Yeah. Okay. I'm sure there's a ton out there.
People can be like, well, what about my platform, right?
You know, I'm sure there's some folks who are experts at wherever they're deploying their code that could maybe come and create a plugin, right?
Absolutely.
And somebody tried to write in support for Google.
What was it?
Google Cloud?
Yeah, Google.
Yeah, GCP.
Google Cloud.
A couple years
ago.
But that was back when there was no plugin system.
And so it got bogged down in just like all the back and forth between core and that platform.
These days, that person could just download that plugin template and start focusing on the platform.
Yeah, awesome.
I'm sure that there's people out there thinking, hey, we could do this for Azure.
Hey, we could do this for
AWS as
well, right?
You know, I'm really blown away about how many people choose the hyperscale clouds, given how complicated and expensive they are.
There was some stat in one of the recent surveys.
I don't know if it was the ESF chip brains one or just a more general developer one.
Anyway, it doesn't matter.
One of the bigger surveys, 75, 78% of the people used either Azure, AWS, or GCP.
And I look at those, I'm like, geez, I don't think 75% of the apps out there need the stuff that those are offering.
And it's so, so much more expensive.
I don't think people fully understand how much more expensive it is to get like a VM on one versus the other.
I did some, I think, you know, it always depends on which one you pick or something.
But for a $20 Hetzner server, it's, I think, $60 on DigitalOcean, $200 something dollars on AWS, and I think pushing up towards $300 for Azure.
And what you get when you go up to these prices, you don't get a better experience.
you get a worse one because all the complexity, all the stuff that you got to deal with, it's not like, well, just here's your server, go with it.
Like, oh, no, no.
There's all these other things you got to bring in.
And it just, it super surprises me that that's the case.
And so, yeah, I don't know.
Yeah.
I built working support for Azure early on.
My goal, you know, I worked for Vork originally, then I made it work for one other platform, which was Fly.
Like, okay, cool.
This isn't tied to one platform.
And then the rule of three, I did a platform in a stage.
Like, okay, now I've gotten all the generalities out.
moving over to VPS as opposed to platform as a service opens up a few new things, but I can put those in internally without making breaking changes in the project.
Yeah. And Azure does have a platform as a service offering, for example. I'm not, I think, I'm sure AWS does as well, although I haven't tried to try to use it. Yeah. So, I mean, they're analogies. I don't know.
Well, I also focused on Heroku.
One of the things for Heroku is it's one of the fastest deployments I've used.
It kind of got a dialed.
Azure was taking like 10 or 15 minutes, so it was hard to do development work against that.
Kim posted this interesting question or comment.
The various deployment mechanisms presumably all need credentials.
Are these provided as NV variables?
Many beginners perhaps don't know what has to do with these.
This project may help.
I agree completely.
So this project is like I'm approaching VPS credentials around SSH as ENV variables.
That's what I've used in the past.
ENV variables being files that have basically key values that you don't put into Git, but you create on the platform, right?
Something like that?
Yeah.
And so the quick start guide will say like export these two environment variables, you know, your IP address and your host password, maybe a username if you've already created a non-root user.
But it goes through and it basically, if you don't give it a username, it tries the default Django user username and it goes through root and whatnot.
It's a little humbling to make these plugins because it shows you exactly where my current knowledge is at.
But it's also a starting place that works.
And so if somebody looks at this and says like, hey, you really shouldn't be using the NB variables.
Here's the current best way to deal with credentials.
we can write that into the plugin and as kim is pointing out it steers all beginners all people from that point forward um into that better usage and it also comes back to that idea that this isn't just for beginners think about all the people out there who are using the inv variables because that's what they learned and maybe if there's something better and the latest version of the plugin steers them towards that as well i've often found there are things that are good for beginners that end up being really helpful for everybody else as well um and this project feels like one of those.
That's very cool. Certainly making your life easier. Everybody wants that, right? Yeah.
Automated a lot of things. Okay. Well, I mean, I'll throw one more thought out there. Like as you're working on the server, the virtual server side of things, I think there's a lot of opportunity to leverage Docker to say like, if you could build an image that is 90% the way there, you could just say, run this Docker image, run this Docker container based on this image.
And what, it doesn't even matter what server it's on. I think there's, I think there's some interesting stuff you could do with docker here but
oh absolutely yes i'll
let you go down that path but i i certainly have enjoyed it um yeah so what's next what do you have to you this is by the way i don't know if we called it out that way this is kind of the 1.0 you mentioned it in passing but this is the 1.0 milestone sort of thing right
yeah the 1.0 for this is really about like people should be able to trust that it's reliable from this point forward it does work works on all three OSs for the officially supported plugins.
I'm going to try to keep a list of plugins that I'm aware of that are being worked on and sort out that whole, you know, how do you manage an ecosystem? But, you know, I've also thought of this as like a gift to the Django community.
I wanted to release 1.0 on Christmas. I couldn't quite get there.
You know, if you listen to Django chat, when the word deployment comes up, there's always this Corona.
of oh
um and i've been there for 20 years excited as well over he loves it yes um
but so this problem has been in jango in the jango world for 20 years how do we deal with the fact that it's hard to deploy jango harder than php harder than some other things and i really think this project kind of answers that question or goes a long way towards entering it um and there's a there are people in the django community who have been kind of cheerleading this project for a while um because if they've seen it i've announced it in public i've kind of done the development in public and at django cons whatnot
yeah so awesome i'm gonna
i'm gonna step back from creating more plugins i'm gonna continue to refine the internals and i'm gonna go back to my own like actual django projects you're
gonna use it rather than build it yes yes you know that's the way to do it you know Well, I think one of the bits of magic of Python and why it's so popular is it's very welcoming to beginners, right?
People coming from science, like we talked about, or other things, they kind of get sucked in and they're like, huh, it's nice here.
Maybe I'll stay.
And, you know, these kind of things sort of tell that same story for web developers, right?
There might be a point where people outgrow this or they don't, but they might.
But it might have gotten them that year's worth of experience running a server or running a platform as a service app and dealing with all of that so that they're then ready to take whatever next step that needs to be taken, if it needs to.
Yeah, it really smooths out that learning process because you just described it.
Python's welcoming people to learn Python.
They say, oh, I want a web front end for this.
Going back to my father not releasing his projects, he was a software developer in the 70s and 80s.
And so for him, deployment was, I need to make my project so good, it can be printed to like 10,000 physical copies.
So it's no fault to him for having those unreleased projects.
So the pathway these days is people learn Python, say, okay, I'm solving my problem with Python.
I want a web front end so other people can access it.
They learn Django because they already know Python.
That's all smooth.
Django is a bit hard, but you can learn it if you know Python.
And then they get to deployment and it's this entirely different class of things to learn.
And that's where that cliff comes in.
And so simple deploy tends to smooth out that.
It basically removes that cliff.
And so you go right from where you are.
I have a project working on my system.
Now it's working on a remote server.
I don't fully understand it, but it's much easier to poke around at the working deployment than poke around at something that you're trying to do that's broken and people end up giving up.
I'm excited about like, yeah,
I'm excited about like opening that pathway for people.
Yeah, absolutely.
That's awesome.
Nice work.
And thanks for doing it.
There's already so much to learn to build a web app to even go from, I know Python to a web app because CSS databases, you know, HTML, JavaScript, there's already enough that you don't need to throw Linux and CDNs and all that at people at the same time, right?
Let them go across the chasm and they'll figure it out on the other side.
All right.
Well, thanks for this project.
Maybe final call to action.
People want to get started with it.
What do you tell them?
Go take a look at the docs.
There's friendly quick start docs, show you how it's used.
And there's pretty comprehensive contributing docs if you're curious to write a plugin or how about otherwise?
Yeah, I guess let's close it out with this.
If you got a platform out there, if you're somebody like fly.io, but a different, consider creating one of these plugins.
It blows my mind, Eric.
I don't know how you feel, but there'll be some major, major service.
And you'll go there and they're like, well, you can use our JavaScript API or you can just write it from scratch.
Like how
much effort is it for one of these companies to spend a week, create a package for their thing and make it go?
And I think, you know, a sort of a similar call to action, like, hey, if you want to make it real easy for people to just switch to your platform, you know, consider following the steps that you talked about to build a plugin for this, right?
Yeah.
And for anybody getting, anybody interested in writing a plugin, feel free to reach out.
I'm happy to make sure that works first time people do it.
Yeah, absolutely.
All right.
Thanks for being here again.
Talk to you
later.
Thank you, Michael.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
This episode is sponsored by Worth Recruiting.
Worth Recruiting specializes in placing senior level Python developers and data scientists.
Let Worth help you find your next Python opportunity at talkpython.fm/worth.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show, open your favorite podcast app, and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air, be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.