Transcript: Django Deployments in 2025 - Eric Matthes

This episode is brought to you by ButtonDown, the easiest way to start, send, and grow your email newsletter.

Hi, welcome to another episode of Django Chat. I'm Will Vincent, joined by Carlton Gibson. Hello, Carlton.

Hello, Will.

And we're very pleased to welcome back Eric Mathis, author of Python Crash Course, creator of Django Simple Deploy, and some other things we'll talk about. Welcome back, Eric.

thank you for having me so i was thinking of you recently because i'm going to be going back to

pycon us for the first time in six years and i remember back in 2019 the first time i met you

in person was at a pycon us i think we we'd communicate online and i remember then i think

it's still the case being shocked that you were not the celebrity there because you then and now

have the best-selling by far python book and yet all these other you know mere mortals were getting

all the attention so i guess i'll tee that up tee that up as do you still fly under the radar at

these big conferences even though i think a majority of people have learned from your book

yeah i that's the phrase i use i do feel like i fly under the radar um but it feels like a nice

balance. Um, people do know who I am. And so if people have stories to tell, they do find me and

I get to hear those stories of what the book has done for, for people's lives, which is really

nice. Yeah. Well, maybe let's, let's start with that. So you're now in the third edition. Um,

I guess just a high level. How has it changed? Because when, when did you first publish it?

It's been in print for a while now. I started writing in 2013. The first edition came out in

2015 and the second edition came out in 2019 i believe and there's a big i did a bunch of

revisions for the second edition um so the second edition was very different than the first um

not in terms of overall structure but cleaned up a lot of the the issues that people had found

and so the third edition was really just mostly updating um things were working and so uh i kept

most of it um third edition like um knock on wood things have continued to work well um

and yeah it's fully up to date so it's been nice yeah well you're one of the few people who can

relate i just did the update to my jenga for apis book and you know sometimes it's as much or more

work to do the update as it is to do the the first one except yes it feels it's somehow less

satisfying, I think, you know, cause, um, but it's, you know, but I guess it's, you wouldn't

do it unless people cared about it and wanted to see it. Right. So it's sort of, it's a little bit

like a band playing their greatest hits. It's maybe not what you and your soul need, but you're

happy to do it. Yeah. Um, pipeline crash course has a big enough readership that it's, it ends

up being really satisfying to, to do the revision is a lot more work than people realize. Um, it's

six to 18 months of full-time to 60-hour weeks. Yeah, it's just a lot.

And yet you wrote the first edition in two years while working full-time as a teacher,

probably primarily in the summer, right? I sometimes think the updates take longer than

the initial thing did. Yeah. I naively thought I could write it in the summer,

draft it in the summer, and revise it during one school year, and it turned into two and a half

years of most of my summers and early night early mornings and late nights and and just at the end

of those two and a half years how are you feeling towards the project uh because it's those this is

those things that take a while to get out they start to burn after a while you know things got

very quiet after it came out um because all that work was done you had this printed book

so it's the space after it you remember rather than getting it over the finish line

Yeah. Okay. Nice.

Yeah.

Well, and maybe it's, hopefully it's, we've talked about this, but you know, you, you are published through No Starch. So you have a team, you know, helping with various things. I think for me, given I don't have a team, I often, you know, kind of want to just like burn my own books and I question my life by the time I get to the end. And, you know, as much as like when I started, I think I'm going to feel so great when I get the update out. By the time I do, I'm just like, I almost hope no one buys it. So I don't have to do that.

again so anyways having a team maybe helps with that um it definitely does the book is

so much better for that team yeah just before we move on i do want to say i bought the i bought

the book for my kids i've got the third edition sat there and i've shown it to them and i've been

like that you know this is what you need to pick up when you need they were like can you teach me

that i'm like no eric can't i'm gonna teach you i have the same conversation with my son can you

teach me, teach me how to do this. Yeah. I'll teach you about like, here's what we're going to do.

Yeah. Right. What was that? I mean, right. As a book author, people want, want you to do a live

or they want a video. And it's like, no, I put all the, like, this is the curated distilled,

perfect version of it. Like just go there. Why do you need me to muddle through my own,

my own stuff? That's kind of how I feel about it. I mean, yeah.

Yeah. You know, it's interesting. Um, and this AI era, um, people, people are still going to it.

And I wasn't sure that that would happen, but people are still going to it because as most of us who use AI tools know, they're only really useful if you know enough to make good use of them.

And so people are reading the book to get that foundation that gives them the background in order to make good use of LLM assistance.

It's quite important to have something that you know is reliable, right?

Right.

there are very few and increasingly less sources that you can say, I know this is reliable. So

Will's book, your book, like these stand out as exemplars of, yeah, actually that's a trusted

resource. Yeah. Well, I think you, you probably don't go right to paying you, you know, think,

oh, like I'll use the free ones. So I'll go to free resources online or free videos. And then

I think with AI, it just sort of pushes out that it's not even like post-tutorial hell. It's just

That like, oh, my God, you know, I'm hearing different things. I just want a trusted voice. And then, you know, you reach for your wallet at some point. Right. Whereas I think those of us like to me, like someone I trust does something. I'm like, oh, yeah, it's I'm saving money for sure. Right. Right. Just because and even if you're a student or someone else, people, maybe it's a stage of life.

Like, I don't think it's just people in different countries with different purchasing power. Like, you have to come to that realization that your time and your energy is worth something and be sufficiently frustrated by what's out there before you say, okay, where am I going to go?

Yeah. Yes.

So I wanted to ask you about your Mostly Python newsletter on Substack, which you've been doing for quite a while now, because that seems to be an area you can write new things rather than endlessly update your book. And in particular, I loved your Django series. I forget, was it 19, 20 part series?

Oh, gosh. Yes. 20 parts.

Yeah. Okay. I got it right. Yeah.

It's at mostlypython.com. I started on Substack, but I left Substack because they're one of these

free speech absolutists that isn't really free speech platforms. And so I'm working through

Ghost now. Well, Carlton, shout out. Are you self-hosting now? Are you using their hosted

service? I'm using the hosted service very happily. Yeah. And you're not charging, are you? Or are

you charging or not i don't think um i there are paid subscriptions um and what i'm doing for free

subscribers is that most of the posts are actually free yeah when they go out um but then i do some

series and typically i've done this series where the the series is available to paid subscribers

for a period of six weeks and then it gets released to everybody and how do you find that

set up working you know i uh stalled the growth of paid subscribers stalled when i did this switch

to to ghost um i also stopped i also made all the posts free for a while because i didn't want to

lose people in that transition um but our lives my my family's life has been all over the place

for the last year and a half we moved from alaska to north carolina and that was a much more drawn

out move than anticipated life under a hurricane and all kinds of things. So I have focused on

making sure the writing is consistent and high quality. Um, and I'll come back to, uh, focus

on whether people are paying or not. Yeah. I mean, I think, I think we featured, I would have

featured like every single one of them in the Django news newsletter. Cause especially, especially

your Django series was just fantastic. I think we, we featured a bunch of them. I was like,

I can't do it every week, but I definitely recommend people starting from scratch.

If they put the time in to do that, they're going to be so far ahead of other resources out there.

Yeah, for people unfamiliar with it, I started the newsletter because I have this book, but the book is self-contained.

It's a thing I work on for six to 18 months, once every three to four years, and then what do I do?

So I wanted to write more regularly, and I wanted to write about a wider variety of topics than just an introduction to Python.

And so it was a weekly newsletter for the first couple of years, and I just moved it to bi-weekly because weekly just got unsustainable after two years.

Bi-weekly feels very nice.

I really enjoyed the writing, and I can make a morning or a day every two weeks to focus on writing.

The Django from First Principles series comes out of a long series going back to Carlton's talk about serving a Django project from one file.

And you were building on prior work as well.

But every time I've heard of these micro Django projects, I've thought like, ooh, this is a good foundation for teaching people Django.

Because one of the things that people get confused about when they first learn Django is they run start project and suddenly they have 11, 13, 17 files and are trying to make sense of all that.

And a lot of, if you're teaching somebody Django, a lot of your work is telling them go to this file, then go to that file.

And so it's really nice to just start with a very simple file, a single file, and then only expand out to other files as needed as the project grows.

So that's why the series expanded out to 20 posts.

I think that's a lovely way of teaching the framework.

Like the bottom line is we're turning web requests into web responses, and that gets

hidden quite a lot, you know, because where do you begin?

You begin by importing a list view and, you know, just defining the model on it.

And then suddenly there's a template and suddenly it all appears and you say, hang on, an awful

lot has happened there.

was if you go back to just there's a view it takes in a request it returns a response there's

the handler that you know is dispatching the request for you there's no middleware there's no

anything it's easy to see what's going on then you can bolt on middleware bolt on you know

whatever you want i think it helps you to grasp what's going on under the hood so to speak

right and then when you've reached the end you're like wow okay this is why all those files were

created by start project and you don't need to go through that process again you just run start

project and you know um where all the pieces are and why they are organized that way um i may turn

that into a mini ebook i i might um take on will's burden and uh just make sure you update it every

eight months and as soon as you update it get an email from someone saying oh like when's the next

update coming or you know psychopg changed or yes i definitely greatly envy the release cadence of

your python book but yeah that's the burden of frameworks there there's a lot of work there that

that's invisible around selecting libraries and approaches that are likely to be stable for a

period of three to five years yeah well i mean one of the things i've i've changed with my books over

the years is how i handle deployment and that leads into probably the rest of our discussion

that's that's the smoothest change ever oh you like to talk about deployment i i like to complain

about deployment. So I was going to say that I have, when I first, my first edition of the

beginner's book, I was trying to mimic, um, there was some rails book where they just like, boom,

like first, first chapter, basically you deployed something. And so I really want to

demystify. And of course it's a horribly insecure thing and Django makes it harder than it needs to

be. And Heroku was designed for rails initially, not Django, but it's possible, but I have

But increasingly, so the most recent version of my beginner's book and the beginner's book, I've moved deployment completely to the end because I heard from enough people.

I used to have progressively more complex projects.

I think there's five.

And then I would have progressively more complex deployments.

So the idea was like, just get something up and then, you know, show how you can button it down and, you know, lock up allowed hosts and all these other things.

But I've had enough people and teachers who've used it in universities say that they just

skipped the deployment stuff because it overwhelmed the students.

Or now that there isn't a great free option, the students didn't have the money for it,

though presumably they have the money for their degree and to buy the book.

So all of which is a lead up to say deployment is a challenge and probably one of the three

or five things that Django could get better.

And I know you have a Django section in your Python Crash Course book and have dealt with this pain from readers a lot.

So I'm done.

That's a setup.

We talked about it before, but there's a lot of new stuff around Django Simple Deploy, so go.

Yeah, so I was looking forward to coming back and speaking with you both about this project, Django Simple Deploy.

And the reason for coming back at this time is I just made the 1.0 stable release of Django Simple Deploy.

people who can't see confidence i'll put a sound effect in there yeah yeah um and so yeah it came

out of teaching people django on deployment for a long time and doing my own deployments

and every time i've done a deployment i have noticed how much time i spend reading platform

documentation whether it's heroku fly platform sh did a lotion um we all spend unless unless you

work for a Django consultancy where you deploy different people's projects every week, I think

most of us spend a fair bit of time poring over the documentation for these platforms not to tune

our deployments, but just to get that initial deployment working. And so the core idea that

I've had for a long time was to ask that question, how can we automate this process from the Django

side rather than from the platform side

because any platform specific

solution is only going to

be useful to the people

who use that platform

and also only as long as that platform

is mindful enough to maintain

that tool.

So Django Simple Deploy

is, the tagline is

deployment for Django knots with deadlines.

Well, that's all of us, right?

Yeah, and

I think that's rewriting the Django deployment

story. Django Deployment has been seen as difficult and fraught with cliffs that you can fall off of

for a long time. And I think this project rewrites that story. So in short, when you install Django

Simple Deploy, pip install Django Simple Deploy, or uv pip install Django Simple Deploy, it adds

a management command one command deploy and then if you want to deploy to fly.io you install the

fly.io plugin so it's a plugin based system and then you run you add Django simple deploy to

installed apps run one command manage.py deploy dash dash automate all and it creates a project

down fly for you and pushes your project and opens it in a new browser.

And so you don't have to, you, you need the fly CLI installed.

Um, and you need an active account on.

fly um but you don't need to read their docs um you don't need to go create a project your project

appears um running in your browser on a remote server as it does locally on your system yeah

it's amazing yeah so can i could i just knock one up in the air for you myself one of the reasons

why the jack so people often like the django docs need a better deployment story because they've got

some you know very very minimal deployment um docs but more or less they've remained a diagnostic

about deployment options.

And the reason it's been

is because there's just no way

of maintaining that.

There are too many options,

too complex,

too likely to change

and go out of date.

And it's just not something

that we can maintain

in the Django docs themselves.

So you mentioned a plugin system

for Django simple deploys.

That's the secret

to being able to maintain

multiple options.

That's right.

And that's why it took so long

to reach 1.0.

Because when I first built the project, like proof of concept, I think was 2019, 2020-ish.

And it started just as a Heroku build pack.

And so it only worked for Heroku and it ran on Heroku's end.

And then I had that shower thought of, oh, how could I do that work in the Django world instead of on Heroku servers?

And a management command is the answer to that.

Because you can run a management command and now you're running on the user's local system.

So you can inspect their system, you can inspect their project.

You can see what platform CLIs they have installed

and that kind of thing.

And so I rewrote that Heroku deployment script

as a management command.

And then I said, okay, can I generalize this?

And so I built in support for, I think, fly.io next.

And then I wanted to do one more

because if you can do something,

if you can support three platforms,

then you've probably solved the generalizability problem.

And so the pre-1.0 version of Django simple deploy supported deployments to Heroku, fly.io, and platform.sh.

But it was all one big project.

And so, yeah, you could already see the maintenance problem, particularly if you're going to try to continue expanding support for different platforms.

So the plugin system is the solution to that.

So I implemented an internal plugin model where each of these platform-specific codebases were their own plugin.

And then I extracted those plugins out into separate repositories.

And so now there's, it's a nice, I think of it as a, what would I call it, a thin tool, thin library and fat plugins.

And probably the fat plugins are better documentation for these platforms than the platforms have themselves in some cases.

Yeah, I want to be careful. When I say you don't need to go to the platform's documentation, you don't need to go. I keep using Fly. Fly is my go-to example when talking about this. So if you want to do your first deployment to Fly, you don't need to go pour over the Fly documentation to get your initial deployment working.

If you're going to maintain a project on fly, you need to read their documentation, need to understand how their deployments work.

But the point is, you can start that learning with a working project.

So you don't have to go pour over their documentation, find the right parts, find the relevant Django parts, hope they're up to date, try to get everything right, get a working deployment and then move on.

You start all that with a working deployment.

One of the really cool things about this is I mentioned that manage.ply deploy dash dash automate all.

That's the fully automated mode.

So that creates a project on Fly for you, configures your project locally, commits your changes, pushes your changes to Fly's server, and then opens your project in a new browser tab.

There are people who love that.

There are people who don't like the idea of a library making a commit on your behalf.

Those are dinosaurs.

The agents are just, all we're going to do is review PRs now.

So there's a configuration-only mode where you create an empty project on fly.

You run manage.py deploy without the automate all flag.

It configures your project for deployment to fly, but it doesn't make a commit.

And so after running manage.py deploy, you get to review the changes.

When you're satisfied with how it has modified your project for deployment,

then you make your commit, and then you run fly deploy.

So you run the platform's deploy command.

And so it adds just a few more steps.

But either of these processes is really nice because, like Carlton,

you just said, it's a nice documentation for the platform.

all the platform-specific configuration

is contained in one Git commit.

Yeah, right, so it's easy to review, yeah.

Or you can just run Git diff

and you see exactly what changes were needed

to make a deployment to that platform.

Now, how have your readers responded to this, right?

Because I know part of this came around the frustration

we both had around changing and updating our books

around deployment things.

What feedback do you get from readers?

Because I know you have a lot of readers.

so i do uh but i have it's not in the third edition and so the third just on your oh it's

just on your website then yeah third edition of python crash course came out in 2021 and i was

really just kind of getting this proof of concept done so fourth edition fourth edition you'll just

slide a sentence in there and then it'll just yeah and it's it's fantastic because it's a nice

abstraction layer you know i since 2015 i have watched the platform that i target heroku for

the first edition and second edition currently the third edition walks readers through a deployment

to platform.sh and so i've just watched those platforms for 10 years with my fingers crossed

that they don't change their process in a way that breaks deployment for the book and so this

this project django simple deploy also solves that problem for authors content creators

if you walk your readers through deployment using django simple deploy as long as one person updates

the plugin when the platform changes their process all your tutorials don't work can i ask about the

plugins eric because i think sure in django we've got third-party apps right traditionally you

right add something to installed apps maybe add a middleware and then django con us last year

simon willison gave a great talk about a new plugin system that right you know i can't remember

what he called it but dj plugins or something i don't know and it's um but it's it's it's

Like you don't have to make a kind of, you don't have to make a change in code.

It will look in your plugin, install plugins at runtime when you fire it up and automatically load the ones that are there.

How's the plugin system for a simple deploy work?

You know, there are some things about this project that make it easier to deal with plugins than some others.

One thing is there's no real back and forth.

So when you run manage.py deploy, there's code in the core library, Django Simple Deploy, that inspects your system.

Are you on Windows, Linux, macOS?

What requirements system are you using?

It also inspects your project.

Do you already have a platform-specific settings block?

That kind of stuff.

How are you structured?

And once it's done, it does invalidation.

If it finds any reason that deployment might not work,

then it bails before making any platform-specific changes.

But once it's done all that inspection,

then it just hands off all the rest of the work

that's done by the plugin.

So there's no back and forth.

We're not just, you know, calling some plugins

and seeing if there's others.

Right.

It's done through a hook,

but it really just, the core Django simple deploy tool

passes a config object to the plugin,

and the plugin, when it first loads,

that sends a config object to core.

And so the core knows what platform is being targeted

and the plugin knows anything it needs to

about the system and the project.

Oh, okay.

And it works quite well.

It's kind of like an API boundary.

You define that boundary

between the core tool and the plugins

and then just define a clean interface.

So what you're really hoping for now is someone to contribute a kind of a plug-in that you

didn't write.

That's the, the mark, Simon Willison said this, the mark of success of a plug-in system

is when you get one that you didn't write.

Yeah.

And so I've done sprints for this project at several Django cons in the last few PyCons

and I've consistently got, gotten 10 to 15 people at my table.

People are really interested in the project.

And some people have really helped move the project forward.

I lose names when I'm in these conversations.

But someone else wrote...

We can add them to the show once, right?

Yeah.

Someone else, also two names, I believe it was either Andrew Hamshar or Josh Thomas.

One of them, they've both contributed and helped me talk through some things.

One of them made a fork and just did a super simple,

well, here's how a plugin interface might look.

And so I just, I looked at that

and that's how I implemented the initial plugin model.

So I'm going to PyCon in May

and I'll stay for a couple of days of sprints.

And so when I do sprints this year,

the focus is going to be who wants to write a plugin.

This episode is brought to you by Buttondown.

That's buttondown.com,

email software for developers like you.

There are hundreds of email marketing software services

out there and they will pretty much offer the same thing. Collect and clean addresses,

send out broadcasts or drip campaigns, get analytics so you can see what's resonating

and what's not. Button Down is designed to hook into the tools that you already care about.

Everything from static site generators like Jekyll or Hugo to payment platforms like Stripe

and Memberful. You can hook your site up to Button Down with just a form element or a simple

REST call. Write emails in Markdown and then get on with the actual work you're supposed to do.

New customers can save 50% off their first year with Button Down using the coupon code JANGO.

And if you email support, they'll white glove migrate to your existing subscribers and archives for free.

And we can say, too, you're also going to do a book signing, at least one, at the PyCharm JetBrains booth, which I'll be there for.

So people should come meet you there.

And I think I might do an open space about it as well, because the nice thing about the open space is it's during the conference and everybody's still there.

From a Django perspective, I'm really excited. Django Simple Deploy is one of the most exciting

projects for me because it's been one of the biggest pain points. It's clearly a solution

that we can get behind as a community. If people have got their own opinions, that's

fine. Just fork the nearest plugin that looks like yours and adapt it to what you need.

It's something that we can have a consistent story to begin as to turn up, how do I deploy

my Django project? Use Django Simple Deploy.

Right. And so it's one of these projects. I mean, I say this with humility. There are

projects like PyTest that I really respect because PyTest is clearly focused on professional

projects, complex projects. But I've also found it's easier to teach beginners testing

using PyTest than it is the standard libraries unit test. PyTest is a library that is so

well implemented so well thought out um that is the best thing for beginners and is the best thing

for many or most professionals and so simple deploy starts out seeing looking like a product

that's just for people who don't already know deployment um but the more you poke at it the

more it becomes just a tool for it's a more efficient workflow for people who already know

deployment for a platform um and it is a tool for authors it's a tool for content creators

it helps platform providers

and platform providers don't want

their documentation to go stale

they want Django developers

to be able to consistently

push their projects to their platform

they're struggling with

keeping their stuff up to date just like we do

so it's a tool

with lots of use cases

I imagine for a platform as well

it's much easier to allocate

the engineering time to fix an issue

on a plugin for one repo

than it is to allocate the more nebulous time

of update the docs to make sure,

well, I don't know what I need,

whereas there's an issue that says

the deployment for platform A is broken, fix it here.

An engineer can fix that in the morning.

Right.

Platform.sh does mention Django Simple Deploy

on their deployment docs as one of the options

for how to get a working Django project on their platform.

So world domination is only weeks away.

Maybe months, but yeah, shortly.

You know, the plug-in conversation is really interesting.

And so I talk about Fly, Platform.sh, and Heroku initially

because it's easier to start talking about platform as a service providers.

But after the 1.0 release, one of the things I was most excited about

was writing a plug-in that targets a VPS

because I have deployed to past providers like Heroku, all of these,

Um, and I've also done deployments to DigitalOcean.

Um, and I like having the option to, to do that range of deployments.

So, um, in the post 1.0 world, uh, I really wanted to see, like, can I write a plugin

that deploys to a VPS?

And so I thought I'd have to like build some abstraction, like, okay, I'll target DigitalOcean.

I'll extract out all the generic VPS utility functions, and then somebody else can write a DSD Linode or Hetzner OVH.

And I think it was Tim Schilling who pointed out, I think one solution is going to work for all of these.

And it wasn't until I had it working that I was like, oh my gosh.

The plugin was initially called DSD-DigitalOcean, and I realized it doesn't know anything about the fact that it's deploying to DigitalOcean.

um you install you give it is the ssh yeah you just say there you go you set two environment

variables um ip address and your your initial password for ssh um and then it does the same

thing it does for other platforms that inspect your system inspect your project and does everything

through that ssh connection the plugin does everything through the ssh connection um it's

a lot harder to write that plugin um than than it is for the the past providers um because it's no

longer just configure the project according to their docs and push it it's oh gosh we have a

for you for people who aren't familiar vps is a virtual private server and so if you go to

any of these vps providers digital ocean linode um hessner ovh any number of them

what you get is a a bare um server so i typically use ubuntu instances because what i've used

locally you can choose debian any number of of images um so you basically get a bare server and

you have to do all the configuration and so the plugin i did rename it it's called dsd-vps

and it's in the Django Simple Deploy organization.

When you install...

So if you wanted to try this,

you have your project that works locally.

You don't even have to install Django Simple Deploy

because Django Simple Deploy is a dependency of the plugins.

So you have your project that works locally

and you install pip install dsd-vps

And that installs SimpleDeploy.

You do add Django SimpleDeploy to your installed apps.

because that's where your management command is coming from.

And now you have to create a VPS instance on your provider

in DigitalOcean that's called a droplet, doesn't matter which platform.

You just create an instance and you set those two environment variables

for your server's IP address and the password you chose for SSH connection.

And then you run manage.ply deploy dash dash automate all

and it does the magic

it inspects your system, inspects your project

and now it calls out and it

creates a new non-root user

on the server

it upgrades the server, reboots

as many times as needed

installs Python, this version

installs it through UV, which is nice

and then

one of the interesting parts is you don't have

a deploy command

from a pass provider

and so i ended up solving this by writing a serve project.sh script um which activates the virtual

environment um system environment variables um it also does some configuration to set up

i'm using gunicorn if i'm saying that right and caddy um and so it it sets up those two as services

on the server uh so that serve project.sh um starts those two services and again in the end

You don't need to know all that right away.

It just pops up your project in a browser.

It's reaching that project through an IP address over HTTP, not HTTPS.

Because I think you need a domain name to use HTTPS.

Well, you'd have to sign the certificate and all sorts of complexities otherwise.

Yeah, so unless you're doing a domain-based project,

deployment right away you're going to get some kind of warning from your browser that this is

a self-signed certificate or you know hdp um but if you're deploying to vps um that's not an issue

because you're that's part of your your process the bigger picture it does you know how many

people have deployed to vps by following digital oceans uh django on ubuntu uh so instead of reading

that whole um that whole tutorial which sends you out to other tutorials how to set up your server

how to set up a firewall how to deploy django it does all that for you i basically followed that

that guide and then updated it with uv updated with caddy instead of nginx um but i i i ended

up with this uh plugin dsd-vps and realized it now works we can't just say django simple deploy

supports fly platform.sh and heroku it apply it supports those three and every vps host out there

yeah which is fantastic yeah yeah well carlton i don't know if this gives you ptsd but you

you spent some time fiddling with vps deployments you know and i still this is exactly how i deploy

still i mean i you know i use ansible instead of a shell script i do you know various bits and bobs

um but absolutely this is so you know um this is something i was looking i've spoke to eric

um about was my button project which is currently on pause um i was gonna try and ship that when i

stepped down as a fellow but my son was ill so i missed my window there but i'll pick that up but

watching eric i've been cheering him along from the from the sidelines here going yes eric yes

yes yes yes yes because this is sort of like from the deployment side of it this is the holy grail

it's like yes something which wraps wraps it up and you can take the plug-in you can fork it you

can customize it you can make your tweaks that you need to make it yours but that basic spin up your

vps provision it get your projects or your code in place on the project and get it running that's

what we need then that's the to have that in place is so super so as i've been watching eric doing

this i've been like oh but that means i can just focus on the monitoring side so for my own tools

and that's much more exciting for me now because i did get exactly this kind of um stress about all

the options and all the configuration channels you could go down and all that it's it's massively

complex um and so you know hat tip to you eric for getting it wrapped up yeah you know um at the

of this recording that um dsd-vps has not been released it is on github um i haven't pushed it

to pipe guy quite yet it's only working on mac os at the moment uh this morning i was just cleaning

up integration tests and the next step is to write an end-to-end test um but that's that's

fairly straightforward uh with every one of these plugins the um difficult work has been getting the

initial deployment to work and once that works the rest of the pieces fall into place can be

bullshit can i ask about i'm who i was to say i'm not an expert on deploying to a vps i've done it

it's worked for my very small projects they're long running uh they're important but they don't

have high numbers of users and so i just get something that works then it works for me for

a long time one of the nice things about these plugins is they become a place to use our shared

collective wisdom yeah and so we have people like you know jeff who works for revsis uh peter

Baumgartner worked for Lincoln Loop or founded Lincoln Loop, he released a project I think two

years ago called Django production, Django dash production. And the goal there was, I think it's a

library you can use and you run a command and it modifies your settings to use like his best

experience around settings at work in production. And so now we can go back and look at projects

like that and blog posts um and take all this like hard-earned experience and dump that into

the plugin and so from that point if we do that from that point forward everybody who uses simple

deploy to run their initial deployment gains the benefit of that that collective wisdom and it

really feels like you know i've watched people um who have really good experience deep experience

with deployment and there's there's no real way for them to to get that out to everybody in a way

that it gets used consistently and so this feels really good yeah no and it's exactly exciting

for those reasons i want i wanted to ask you about the the sort of the second deploy so

i you know i i django deploy dash dash automate all and you know my new server and my provisioning

and then i i make some changes i you know i commit my new changes i want to deploy again i just run

django deploy oh okay let me take a step back so when uh people want to make their own plugin

um there's a better story than you know fork the existing plugin and modify it

um i made a plugin called dsd plugin template or i shouldn't say a plugin it's a project

and so it's just a repository it's in the django simple deploy organization

and so there's documentation for this in the django simple deploy docs under the plugins

section if you want to make a new plugin so carlton no i'll say will will likes will's the

guy right well i'm i've been i've been moved away by carlton but yes i have i still have a book on

it and i but yeah i i had my my learn django.com site it was all doctor and i've you've forgotten

of the golden rule don't do what carlton does just because with a healthy dose of uh you know

caution and you know anxiety i have followed carlton down this path but i still am familiar

with docker a little bit all right so will takes carlton's uh advice to not follow him too closely

to heart and says i'm going back all in on docker and will wants to write a plugin called dsd dash

vps dash docker so his best approach is probably not to just fork my plugin his best approach is

to download um not clone download this uh dsd vps um plugin template sorry dsd plugin template

and it gives you it'll ask you like four questions what's your target platform

are you supporting automated the fully automated approach what informal name do you want for it

and then it gives you a plugin with the right names in the right places and it gives you tests

and so you can run pytest right off the bat and you have a working set of tests for your plugin

So all the plumbing is there, and so you get to drop into just the part of the plugin that actually does the configuration and setup.

And so where I'm writing this serveproject.sh, Will would write a Dockerfile.

And so it's nice, you get a clean plugin to start with, and so you're just focusing on your expertise, which is really nice.

Right. But I'm going to come back to my question about the second deploy, because the first deploy, you have to provision the server. But the second deploy, you just kind of, well, the second time, when you update your running Django application, you have to refresh the code for the files somehow, either a pull or a push, or somehow you have to get your new code on the server.

You have to update your virtual environment, you perhaps run your migrations, you perhaps create static files, and then you reload your service, which is running the application.

I haven't looked into it, so I don't know.

How do you handle the state-changed error?

Oh, no, I actually need to do the whole provisioning thing

versus, no, no, all of that's in place

and I can just whiz through

with the much quicker step of redeploying.

Yeah, so a fun question for this project has been,

what exactly does the word simple mean?

What are the boundaries of the project?

Simple to who?

Yes.

So simple for the end user.

So good question.

It should be simple for the end user to do their initial deployment.

It should also, take a step back.

There's a section of the docs that talks about what it takes to write your own plugin

and the things you need to think about and the questions you need to answer before writing any code.

One of the questions is, can deployment to the target platform be fully automated?

One of the other questions is, what's the concluding message you're going to give to people when this deploy command finishes?

And so what it looks like, there's a .py file called deploymessages.py, and there's a success message.

And so you have to write your success message to people.

So they've run manage.py deploy,

dash dash automate all, I'll say,

and their deployment pops up in the browser.

And so that's their first deployment.

And Carlton's question,

okay, they make projects,

changes to their project locally.

How do they push that next change?

So in your success message,

you need to be able to answer that question.

So the PaaS providers,

that's fairly straightforward.

Somebody pushes to fly.

The fly success message is pretty short.

It says deployment should be successful.

You should have seen your project pop up in a new browser.

If you didn't, here's the URL you can go to.

To make changes to your project, make your changes locally, make a commit, rerun fly deploy.

And that's about as simple as it is for most of the past providers.

For a VPS, we have to answer that question.

Right, good.

And so I haven't written that success message yet,

but I think for my approach

of Gunicorn Caddy as services,

I did set up a Git push.

So I think the second deployment is

make your changes, commit them, run Git push,

and then I'm not quite sure how to restart the services.

And that's a question, you know,

I'm not sure how much responsibility I'm going to take in simple deploy for that second deployment.

That's not the main goal.

I need to know that people can do a second deployment.

But when we're talking VPSs, it's kind of a bigger open question.

The goal is, you know, I have felt like I'm standing in the shoes of the people who started all these past providers by writing this sort of product at S8 and writing a script for it.

Like, they must have gone through these same processes and answered the same questions.

Um, so I, I might just put a small script on their, their server that says like, you

know, run this SSH command to restart all those services.

Or I might say, you know what, that's, that's too varied to do.

And the only promise for this project might end up being, we got you your initial deployment.

Here's the kinds of things you're going to need to do to maintain it.

Yeah.

And when you talk about getting, gathering the collective wisdom of the Django community,

So, you know, people can input there as to options.

People can blog about, oh, you know, this is what I do next.

And opinions will form.

Yes.

Can I ask?

Yeah, I asked.

Sorry, go ahead.

Go ahead.

Well, Carlton saw this yesterday.

I posted a question on Mastodon.

So I said all the PaaS-focused plugins have two modes.

There's the automate all mode.

where it does everything for you,

including making your commits and pushing your project.

And it has a configuration-only mode

where it does a configuration, which is the hard part.

You make the commit, which is easy,

and you run the platform's deploy command, which is easy.

It should be easy.

With a VPS, I have really struggled

to come up with a configuration-only mode

because if you're starting with a bare server there's a bunch you need to do to update the

server create a non-root user reboot it as needed install python certainly maybe some other things

um you need to start these services at some point you need to configure like an ssh key pair

for um for get push if that's how you're you're handling code and so configuration only mode

feels like, ooh, it's not just one step for configuration.

It might be like, I don't know if I want to do like

manage.py deploy dash dash configure remote.

Manage.py dash dash configure local.

Manage.py dash dash push.

So, you know, I'm open to, I mean,

people writing their own plugins

can make this as complicated as they want.

Like you can recreate the entire CLI for Roku if you want.

i don't want to do that um it doesn't need to stay super simple it should just be clear and

simple for the end user yeah and i think with yeah that's a nice way of thinking about it is

a scope if you give an example that's that's sufficient i always felt with um vps is this

sort of two steps okay you first of all you need to provision your vps with your provider so okay

that's step zero but then step one is get the the web server installed get the you know whatever

other dependencies are installed and then step two was deploy your application which was code

virtual environment you know migrations static files etc right and running it

if you just have one flag well do you just go to step well step zero before step one

or after step one.

Right, and I haven't sorted out yet.

You know, with the past providers, it's very clear.

Here's your local work, here's your remote work.

With the VPS, I haven't quite sorted out

if there's more back and forth that has to happen.

The one other big thing that's different

about supporting a VPS is you need to do some things

outside of the local project.

So for setting up a Git push,

I believe you need to configure those SSH keys

outside of the local project.

And so as soon as you're writing,

writing anything to a location outside of the user's local project they can no longer undo that

with git yeah and so you know one of the the original promises of the project is all changes

made in a single commit you can approve them or roll them back as needed um this is a little

different but again to throw all that up in the air i mean somebody who's looking for a tool that

automates deployment to a VPS and saves them all that work,

probably wants all that done.

You probably want, like, your project running in that VPS

if you're starting from a bare VPS.

I'm just thinking one of the things,

one of the reasons why I started with Heroku

and then I switched to Fly and then I've gone back to Heroku

is because Heroku is one of the very few

that still supports Git deployments

as opposed to spinning up, you know, a Docker container.

And of course, it sort of does that behind the scenes. But one of the challenges I found with Fly is I basically had to give people kind of a Docker file. And I really disliked having to say, there's this thing called Docker and containerization, but don't worry about it. Just use this thing, trust me, and we're not going to get into it.

But that seems, you know, that is the new way that everyone's doing it behind the scenes.

And so I guess I wonder for you, with the Heroku support, is that, are you using the

Git-based or are you also using a Docker kind of file thing with Django Simple?

Yeah, for Heroku.

The Heroku plugin is Git-based.

Okay.

But the other ones you are not, right?

You need to generate.

Well, I mean, I guess this has changed to be fair.

And I was working a little bit with Fly at the time.

were automating a little bit but it's still ultimately like i would have you need to

and maybe i'm dating myself but you needed to um the yeah there's the deployment was different like

you could get ignore some things and heroku wouldn't have it but like fly would still see

it unless you added a you know a docker ignore um file and so you know it would create a docker

a docker file for you but if you didn't know to ignore it then anyways i just found all of that

frustrating you'd have things like your virtual environment pushed to fly yeah right and and that

was relevant because at the time i was trying to step through progressively more complex deployments

and yet it just felt very hand wavy i didn't really see a nice progression there other than

being like just do these things like okay yeah we're gonna do docker don't worry about that

you need a docker ignore file don't worry about that um and then again at the time fly was going

undergoing a lot of changes to make it better but it meant that the normal cycle of these

deployment places you know changing their docs was even more accelerated and um

but yeah i hopefully it's more stable now it probably is yeah i mean i i've had the same

frustrations that will has had so in python crash course chapter 20 the last chapter of the book

the last section of that chapter is about deployment. And it's the one part of the book

where I felt that I wasn't really teaching people things. I was telling them to write this file,

do this, trust me. The whole book, the whole book. And then you're like, just do it this way.

Yeah. And so Django Simple Deploy, I've had one person criticize the project,

and that was somebody who knows deployment way better than I do and probably better than

most of us. And their only complaint was, oh, you can't automate it all. People won't learn

how this all works and i think i could have another i think i could have another dinner

with that that person how could you teach python without first teaching c and assembly and you

know how dare you go to the beach and melt some sand um so uh jingo simple deploy really changes

the way you teach that because if you wanted to use uh simple deploy to target fly in your book

you could have people install simple deploy the fly plugin run manage up high deploy dash dash

automate all if you want um you'd probably do the configuration only route so they make their

and run their the platform command but then you're free to say um the tool made a docker file for you

you don't have to show the docker file so if that changes you're not worried about like does the

text of the docker file in your book match the current one and so you can talk about what a

docker file is and what it does and what parts people should look at look for and not worry if

there's a few more sections or some sections are locked out it always felt to me like deployment

a complex deployment any deployments complex they just are um this is one of the problems but

deployments kind of like a grandfather clock or something and if if it's not moving it's really

difficult to work out what all any of the bits do because it's massively complex and you can't

really see but if you get it moving and you can watch it ticking and you can watch the cogs go

around and you can watch the hands move and you can watch the little cuckoo come out if it's got

one of those you can learn you can say oh that bit does this and that you know you know i think

that's really useful yeah so i'll use will as the the subject for this um but it goes for anybody

writing django tutorials um so one of the reasons that will would probably choose a configuration

only approach for a book is you could tell your users you know install simple deploy install the

fly plugin run manage.py deploy without the automate all and you can tell your readers now

run git diff now look at the changes you were made and you can point them to some broad changes to

look for but again not getting lost in the weeds that tend to change um and it's so it's a tool

that simplifies things but also like if you use it right uh deepens people's understanding in a

much better way because deepening people's understanding of something that works is way

easier than trying to get people to understand something that they made one typo that makes

everything fall apart there's a there's a semicolon missing um i was gonna say there's one other

point to this and i i think you guys can see that like this project has all these subtleties to it

um one of the reasons okay one pattern we see in platforms deployment docs is they give you a very

simple docker file they give you a very simple proc file or very simple set of changes to make

to your settings file and what i see them all doing is giving the minimal set of changes because

every additional change you make ask the user to make to their project the more chances they have

of a failed deployment and no platform wants people to fail their initial deployments because

you'll walk away if those files and changes are being made for you being written for you and made

for you there's no need to to simplify it and so when we're talking about a docker-based uh

deployment i had this interaction with jeff triplett where i you know my docker file for fly

was copied from fly documentation and jeff looked at it and said hey here's a way to make it much

lighter um and like cool okay and so you can also add sections um so you know i go to peter

bone gardener's jango production um there are settings changes that he's making in that project

that would be beneficial to a good number of people and we can just dump those into the file

because it doesn't matter if it's 30 lines of modified settings if you're not having to take

tell people to type it or copy it or yeah yeah and just to make this even more insular and to

give jeff a shout out not that he needs it but i mean jeff basically taught me docker for the

professional's book. And then when I was, I spent far too much time with fly, but it ended up that

I consulted with them and wrote the initial docs and helped update the Docker file and a whole

bunch of things. And a lot of that was just sort of showing it to Jeff and being like, what do you

think of this? And he always had improvements. So I would suspect that the, still the Docker file

that's in there might've been one that, that Jeff wrote because the initial version they had was

something that an engineer who knew what they were doing but didn't know jango python clearly

just looking at it it was completely unoptimized and so right um yeah jeff and i did some prs

on that and yeah it must be must be odd for jeff to be in that situation sort of like a grandfather

like oh look at you know but but like how do people unless you have this grandfather clock

And I love that analogy, Carlton, like, how do you know how to really tweak or fiddle these things and see the results? Like, that's absolutely right. I hadn't thought about it quite like that. Without it up and running, it's difficult to see how these changes matter and to even use them.

And I guess many people, they're hesitant to deploy something and pay that cost, that learning cost, because you do need to spend a little bit to have it going.

But nothing like learning on the job, right?

Nothing like learning on your own project rather than taking down your company's servers by accident.

Yeah, this project is an interesting boundary between the Django world and the non-Django world.

And so we're speaking about people like Jeff and Peter from the Django world, giving input about what tends to work well for Django.

I've had some interactions where people from specific platforms have popped in and said, hey, this is what does work better on our platform.

So they'll know something about how their platforms read and ingest the Dockerfile.

And they'll say, for our platform, you should include this piece or modify that.

And so this project sitting at the boundary layer, like that, that plugin is really that

boundary layer between the Django world and the platform world.

It gives a place for people with expertise on both sides of this, this world to share

their, their learnings.

That just sounds, you know, that just sounds such a wonderful world to be in, right?

You know, as this, you know, as it matures and, you know, the plugins grow, there'll

be a kind of canonical place you can go and look even if you don't use it you can go and look and

learn and see some things that you might not have known otherwise yeah uh it's it was really nice

for me to see that i with um the vps work that we don't need a separate plugin free to the the hosts

um it kind of i was a little intimidated by thinking about how big the the plugin ecosystem

and might grow.

But it really shouldn't.

Clearly one for each proprietary platform provider.

And there's no limit.

If somebody has this super customized workflow

that they want to write a plugin for,

there's nothing that stops them.

But we should be able to basically formulate

a good like gun-to-corn caddy approach for VPS,

a good Docker one.

And that's separate from the gun-to-corn caddy.

But like the VPS that I'm using,

I use SQLite on the server.

Um, I don't, I don't want an explosion of CLI args, but, uh, one arg I'm going to add is dash dash DB. And so you can choose SQLite or Postgres, um, because that's just a, a switch in the configuration. I don't want to put like DSD dash VPS and there's a flag for whether you want to use Docker or, uh, Gunnicorn or, or I shouldn't say that because you can use that within Docker.

yeah i see i see i see your point yeah yeah carlton you have a puzzled face does that mean

a question no i was just saying i was just thinking about you saying you add a cli flag

for specifying your dv rather than like putting these kind of things in a config file you might

have you know or a 2e that does a quiz and says no right because like right command line flags

are a bit of a pain to type right i don't know anyway this is just a thought it was literally

just a i was dazing off into a creative world yeah that's interesting i think i lean towards

um cli args because it's it's a constraint i know i don't want too many

whereas starting to find a config file the whole goal originally was to you run a couple commands

and your product is deployed.

Yeah.

And I guess if people need something more complex,

then that's when Do Your Own Plugin comes in

because you can imagine things like S3 values

and a secret store and a DB that you need to connect to

and a Redis cluster that you want for caching

and simple deploy the default plugins

don't need to provide that.

Right, right.

And so, you know, one of the things I wanted to kind of close out with is where am I going from here?

You know, what's simple?

And so if we're talking deployment of a simple project to fly Heroku, maybe your first VPS, it's fairly simple.

When you talk about AWS and the services you're naming, clearly not so simple anymore.

But I think the name still works, because the name is there's a simple story for deployment in the Django world.

And so if somebody who knows AWS well writes that plugin, then, yeah, there's a simple deployment story for deploying to AWS.

Maintaining it might not be simple, but the initial deployment.

and so again it's a it's a good story for that because you think about all the work people go

to like learn how to get something functioning off of aws yeah no it's a lot easier to have

something that works that you poke at yes all right we're at that point in the show i need to

ask you again you have the wand it can't be around deployment but we're still doing we're

still doing django there must be something something else that you'd like to wave away

you know i gosh i i have a post every year every january i kind of go through that question of do

i still want to be using python um you know am i using it for the right reasons or am i using it

because i already know it um and i stay with python because it it lets me solve the problems

I care to efficiently and effectively.

And so that's the same thing

that keeps me on Django.

My work going forward

is going to be to continue

to clean up this core plugin boundary

for SimpleDeploy,

clean up the testing story.

If it becomes an established project,

we'll have a separate conversation

in a year or two

about the entire testing story

because it's pretty interesting.

But I also want to go back to my own Django projects.

I have a project focusing on math education,

some projects about music and whatnot.

So Django works for me.

Like, I don't run into any of the rough edges.

And there's enough shared knowledge out there

that when I run into something that doesn't work,

I can figure it out.

People answer my questions.

I've occasionally run into some libraries.

I think it was like there's a modified prepared traverse tree, something like that, Django MPTT.

And I was using it for, yeah, so that math project, it tags math problems.

So the spirit of that problem is your kid hates math, your kid loves Legos, your kid is learning algebra.

Can I find some math problems that are about Legos that use algebra?

You click those tags and have a bunch of math problems that your kid would say like, oh, I didn't know math could be like this.

So I used that library

and it didn't do one thing quite right,

but I was able to fork it and modify it

and communicate that with the founder.

So I think the things I'm most excited about in Django

is probably Django.NET Space

because seeing this steady stream of newer perspectives

who already have their hands in the Django code base

feels really good.

Yeah, no, absolutely.

It's, you know, it's a massive, it's a wonderful innovation, I think is the way I would phrase it.

All right.

Well, we could keep talking for quite a while, but we will have show notes for all these things.

Everyone check out Django Simple Deploy.

Eric, thank you for taking the time, as always.

Yes.

Yeah.

Wonderful.

Thank you for having me.

All right.

We'll see everyone next time, DjangoChat.com.

And bye-bye.

Bye-bye.

This episode was brought to you by Button Down, the easiest way to start, send and grow your email newsletter.