Transcript: Django Deployments in 2025 - Eric Matthes

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hello, Will.

Welcome back, Eric.

And I remember back in 2019, the first time I met you in person was at a PyCon US.

I think we'd we'd communicate online.

And I remember then, and 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.

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.

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.

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 this 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.

I just did the update to my Django 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 it feels it's somehow less satisfying, I think, you know, because 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.

Um Python Crash Course has a big enough readership that it's it ends up being really satisfying to to do the revision.

It's a lot more work than people realize.

Um it's eight it's six to eighteen months of full-time to sixty hour weeks.

Um yeah, it's just a lot.

Yeah, sorry, and yet you wrote the first edition in two years while working full-time as a teacher, probably primarily in the summer, right?

Like I sometimes think the updates take longer than the initial thing did.

Uh 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 it in two and a half years of most of my summers and early night, early mornings and late nights.

Uh because it's those this is those things that take a while to get out, they start to burn after a while, right?

Um, because all that work was done and you had this printed book.

Yeah, okay, nice.

Yeah.

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 before when I started, I think I'm gonna 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.

The the book is so much better for that team.

Yeah.

I've got a third edition sat there and I've shown it to them, and I mean like that, you know, this is what you need to pick up when you need to like, can you teach me that?

I'm like, no, Eric can't.

I'm gonna

teach you.

Can you teach me, teach me how to do this?

Yeah, I'll teach you about like here's what we're gonna do.

Yeah, yeah, all right.

Like, just go there.

Why do you need me to muddle through my own uh my own stuff?

That's kind of how I feel about it.

I mean Yeah, yeah.

Um, in this AI era, um people people are still going to it.

And I wasn't sure that that would happen.

Um, but people are still going to it because as most of us who use um AI tools know, um they're only really useful if you know enough to make good use of them.

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

And there are very few real 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.

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.

Right.

Just because and even if you're a student or someone else, people I maybe it's a uh 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 gonna go?

Yeah.

Yes.

And um in particular, I loved your Django series.

I forget, was it 19, 20 part series?

Yes, 20 parts.

Yeah, okay,

Yeah.

I started on Substack, but I love 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.

Self-hosting now?

Yeah.

Yeah.

Or are you charging?

You're not, I don't think.

Um and what I'm doing for free subscribers is that most of the posts are actually free 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.

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, and 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 you.

Uh focus on whether people are paying or not.

I think we we featured a bunch of them.

I was like, I can't do it every week, but but I definitely recommend people, you know, starting from scratch, like if they put the time in to do that, they're gonna be so far ahead of um other resources out there, you know.

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

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

Um, bi-weekly feels very nice.

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

Um the Django from First Principles series comes out of uh a long series going back to Carlton's talk um about serving a Django project from one file, and you were building on prior work as well.

Um, but every time I've heard of these micro Dango 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.

Um 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.

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

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

Like the bottom line is we're turning web res web requests into web responses, and that gets hidden quite a lot.

You know, because you or 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 it's like, hang on, an awful lot has happened there.

Whereas 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.

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

And as soon as you update it, get an email from someone saying, Oh, like when's the next update coming, or you know, Cycle PG changed, or I definitely uh greatly envy the release cadence of your Python book.

But yeah, that's the burden of frameworks.

Yeah.

And that leads into probably the rest of our discussion.

So I was gonna 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 increasingly so the most recent version of my beginner's book and the AP um the beginner's book, I've moved deployment completely to the end because I heard from enough people.

I used to have progressively complex more complex projects.

I think there's five, and then I would have progressively more complex deployments.

Um 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 in universities say that they just skip 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.

Um 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 tough we've we talked about before, but there's a lot of new stuff around Django Simple Deploy.

So go.

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

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

And people who can't see called this.

Yeah.

Um and so yeah, it came out of teaching people Django uh 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, um, whether it's Heroku, uh, Fly, Platform SH, DigitalOcean.

Um, we all spend, unless unless you work for a Django consultancy where you deploy different people's projects every week, um, I think most of us spend a fair bit of time pouring over the documentation for these platforms, not to tune our deployments, but just to get that initial deployment working.

Um and so the the core idea of 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?

Um, because any platform specific solution is only going to be useful to the people um who use that platform, and also only as long as that platform uh is mindful enough to maintain uh that that tool.

So Django Simple Deploy is uh the tagline is uh deployment for Django knots with deadlines.

Right.

Django deployment has been seen as difficult um and fraught with cliffs that you can fall off of for a long time.

Um and I think this project uh rewrites that story.

So in short, um when you install Django simple deploy, pip install Django simple deploy or UV pip install Django Simple Deploy, um it adds a management command, uh one command deploy.

Um and then if you want to um deploy to fly.io, uh you install the fly.io plugin.

So it's a plugin-based system.

Um and then you run, you add Django Simple Deploy to installed apps, um run one command, um, manage.py deploy dash dash automate all um and it creates a project on 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.

One of the reasons why the J so people are 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 they've remained diagnostic about deployment options.

And the reason has been is because there's just no way of maintaining that.

There's too too many options, too complex, um too likely to change and go out of date, and it's just not something that we could maintain in the in the Django docs themselves.

So you mentioned a plugin um system for um Django simple deploys.

That that's the the the secret to being able to maintain multiple

options, you'd say.

And that's 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.

Um, and it it started just as a Heroku build pack.

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

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

Um, 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, um, you can see what uh 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 can I generalize this?

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

Um, and then I wanted to do one more, because if you can do something, if you can support three platforms, then you've probably um solved the general generalizability problem.

Um and so the pre-1.0 version of Django Simple Deploy supported deployments to Heroku, Fly.io, and platform.sh.

Um, but it was all one big, one big project.

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

So the plugin, the plugin uh system is the solution to that.

So I implemented an intern internal plugin model where each of these platforms specific um code bases 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 uh uh what do I call it, a thin um tool, a thin library and fat plugins.

Um when I say you don't need to go to the platform's documentation, you don't need to go.

I 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 gonna maintain a project on fly, you need to read their documentation, you need to understand how their deployments work.

Um 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 Jang Django parts, hope they're up to date, try to get everything right, get a working um deployment, and then move on.

You start all that with a working deployment.

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

That's the fully automated mode.

Um a lot of people, so that creates a project on you, on fly for you, configures your project locally, commits your changes, um, pushes your changes to fly servers, and then opens your project in in a new browser tab.

Um there are people who love that.

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

Well, those are

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

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

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

Um when you're satisfied uh with how it has modified your project for deployment, then you run, you make your commit and then you run fly deploy.

Um so you run the platform's deploy command.

And so it adds just a few more steps.

Um but either of these processes is really nice because it, like Carlton, you just said this 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.

Or you can just run git diff and you see exactly what changes were needed to make a deployment to the platform.

Because I know part of this came around the frustration we both had around changing and updating our books around deployment things.

Um what feedback do you get from readers?

Because I know you have a lot of readers.

And so the third

Third edition of Python Crash Course came out in 2021, and I was really just kind of getting this proof of concept done.

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 uh change their process in a way that breaks deployment for the book.

And so this project, Django Simple Deploy, also solved that problem for authors, content creators.

Um, 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 still work.

Because I think in Django, we've got third-party apps, right?

Traditionally, you'd add something to installed apps, maybe add a middleware.

And then uh DjangoCon US last year, Simon Willison gave a great talk about a a new plugin system that you know uh I can't remember what he called it, but D 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 um 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 how's the plugin system for simple deploy work?

Uh one thing is there's there's no real back and forth.

Um so you when you run manage.py deploy, there's code in the core library, Django SimpleDeploy, that inspects your system.

Are you on Windows, Linux, Mac OS?

Uh, what requirements system are you using?

Um, also inspect your project.

Um, you know, do you have already have a platform-specific settings block?

Um, that kind of stuff.

How are you structured?

Um and once it's done, it does some validation.

If it finds any reason the deployment might not work, then it bails um 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 is done by the plugin.

So there's there's no back and forth.

We're not just you know calling some plugin tools.

Right.

It's it's done through a hook, um, but it really just um the core Django Simple Deploy tool passes a uh config object to the plugin, and the plugin, when it first loads, um sends a config object to core.

And so the the core knows what platform is being targeted, um, and the plugin knows uh anything it needs to about the the system and the project.

Okay.

It's a pretty it's it's kind of like an API boundary.

You know, you define that, define that boundary between the core tool and the plugins, um, and then uh just define a clean interface.

That's the the Yes the mar I Simon Willison said this, the mark of success of a plugin system is when you get one that you didn't write.

Yeah.

Like people are really interested in the project.

Um, and some people have really helped move the project forward.

Um I lose names when I'm in these these conversations.

Um but someone else.

Yeah.

Uh someone else um I'll throw two names.

There's I believe it was either Andrew Hamshar or Josh Thomas.

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

One of them made a fork and just did a super simple here's how a plug-in interface might look.

And so I just I looked at that and that's how I I implemented the initial um plugin model.

Um so I'm going to PyCon in May, and I'll stay for a couple days of sprints.

And so when I do sprints this year, the focus is gonna be who wants to write a plugin.

That's buttondown.com.

Email software for developers like you.

There are hundreds of email marketing software services out there, and they all 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 Django, and if you email support, they'll white glove migrate your existing subscribers and archives for free.

So people should come come

meet you there.

Because the the nice thing about the open space is it's during the conference and everybody's still there.

So Django Simple Deploy is one of the most exciting projects for me, is because it's been one of the mass the biggest pain points.

And it's right like a clearly, a solution that we can get behind as a as a community.

And if people have got their own opinions, that's fine.

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

But 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.

And so it's it's one of these projects.

I mean, I say this with humility.

Um, there are projects like PyTest that I really respect because PyTest is clearly uh focused on professional projects, complex projects.

Um, but I've also found it's it's easier to teach beginners testing using PyTest than it is the standard library's unit test.

Uh PyTest is a library that is so well implemented, so well thought out, um, that it's the best thing for beginners and it's 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 to a tool for it's a more efficient workflow for people who already know deployment for a platform.

Um and it's a tool for authors, it's a tool for content creators.

Um, it it helps platform providers.

I mean, platform providers don't want their documentation to go stale.

They want Django um developers to be able to consistently push their projects to their platform.

They're struggling with you know keeping their stuff up to date just like we do.

Um so it's a tool with lots of use cases.

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.

Um, platform.sh does mention Django Simple Deploy on their deployment docs as one of the options for how to get a a working Django project on their platform.

Yeah.

Um, you know, the the plugin conversation is really interesting.

And so I talk about Flyplatform.sh and Heroku initially because um it's easier to start talking about um platform as a service provider.

Um but with after the 1.0 release, one of the things I was most excited about was writing a plugin that targets a VPS.

Um, because I have deployed two past providers like Heroku, all of these.

Um and I've also done deployments to DigitalOcean.

Um and I like having the option 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 like generic VPS utility functions, and then somebody else can write like a DSD uh Linode or Hetzner, OVH.

Um, and I think it was Tim Schilling point out like uh I think one solution's gonna work for all of these.

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

I I the plugin was initially called DSD-digitalOcean.

Um, and I realized it doesn't know anything about the fact that it's deployed to DigitalOcean.

Um you install

You just say that off you go.

Um and then it does the same thing it does for other platforms.

It inspects your system, inspects your project, and does everything through that SH 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 bear for view for you who aren't familiar, VPS is a virtual private server.

And so if you go to any of these VPS providers, DigitalOcean, Linode, um Hetzner, 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 images.

Um so you basically get a bare server and you have to do all the configuration.

And so the plugin, I I did rename it.

It's called DSD-VPS.

Um, and it's in the the Django Simple Deploy organization.

Um when you install, so if you wanted to try this, you have your project that works locally.

Um 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 simple deploy.

You do add Django SimpleDeploy to your installed apps, um, because that's where your management command is coming from.

And now you run, you you have to create um a VPS instance on your provider, and digital ocean that's called a droplet, doesn't matter which platform, you just create an instance and you you set those two environment variables for your your server's IP address and the password you chose for SSH connection.

And then you run simple deploy, sorry, you run manage.py deploy dash dash automate all, and it does the magic.

It inspects your system, inspects your project, and now it calls out and it um creates a new non-root user on the server, it upgrades the server, reboots as many times as needed, um, installs Python that this version installs it through UV, which is nice.

Um 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 serveproject.sh script, um which activates the virtual environment, um, sets some environment variables.

Um it also does some configuration to set up.

Uh I'm using Gunacorn, if I'm saying that right, and CADI.

Um and so it sets up those two as services on the server.

Uh so that serveproject.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.

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

Um, because I think you need a domain name to use HTTPS.

So unless you're doing a domain-based um deploy 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, HTTP.

Um, but if you're deploying to a 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 a VPS by following DigitalOceans 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 and updated it with Caddy instead of uh 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 Flyplatform.h and Heroku.

It affli it supports those three and every VPS host out there.

Yeah.

Yeah.

I mean, I uh you know, I 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 at, I've spoken to Eric um about with 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 to 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 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.

It is on GitHub.

Um I haven't pushed it to PyPI 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 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 I ask about I'm oh, I was gonna say, I'm not an expert on deploying to a VPS.

Um I've done it, it's worked for my very small projects.

They're long running, uh they're important, but they 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 Revsys, uh, Peter Baumgartner works for Lincoln Loop or you know, founded Lincoln Loop.

He released a project uh, I think two years ago called Django Production, Django Dash Production.

And the goal there was, I think it's a a library you can use and you run a command and it modifies your settings to use like his best uh experience around settings at work in production.

And so now we can go back and look at projects like that and blog post 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 get that out to everybody in a way that it gets used consistently.

And so this feels really good.

I want I wanted to ask you about the the the sort of the second deploy.

So I you know, I I I Django deploy dash dash automate all and you know my my new server and my provisioning and then and then I I I make some changes, I you know, I commit my my new changes and I want to deploy again.

I just run Django deploy.

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.

Uh and so it's just a repository, it's in the Django Simple Deploy organization.

And so that there's documentation for this in the Django Simple Deploy docs under the plugins section.

Uh, if you want to make a new plugin, so Carlton, no, I'll say Will.

Will likes Will's the Docker

guy, right?

It was all Docker.

Don't do what Carlton does, just because Carlton doesn't do it.

But I s I still am familiar with Docker

a little bit.

All right.

And Will wants to write a plugin called DSD-VPS-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.

Um, and it gives you it, it'll ask you like four questions.

What's your target platform?

Um, are you supporting automated the fully automated approach?

Um what informal name do you want for it?

Um 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 um right off the bat, and you have a working set of tests for your plugin.

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

And so where I'm writing this sort of project.sh, Will would write a Docker file.

Um, and so it's nice.

You get a clean, clean plug plug-in to start with, and so you're just focusing on like your expertise, which is really nice.

Right.

But the second deploy, you just kind of well, the the the this the second time, when you update your running Django application, you have to refresh the the code for the files somehow, I don't know, a pull or a push, or some somehow you have to get your your new code on the server.

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

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

How how do you how do you handle the fact how do you f how do you handle the state change there of, oh no, I actually need to do the whole provisioning thing versus no no no, all of that's in place and I can just whiz through with the with the much quicker step of redeploying.

Um what are the boundaries of

Uh so simple for the end user.

So good question.

Um it should also so take a step back.

Um there's a section of the docs that talks about w 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.

Uh one of the questions is can deployment to the target platform be fully automated?

Um one of the other questions is what's the concluding message you're gonna give to people when this deploy command finishes?

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

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

So they run manage.py deploy, um, dash dash automate all, say, um, and their deployment pops up in the browser.

And so that's their first deployment.

And uh 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.

Um so the the past providers, that's fairly straightforward.

Somebody push it to fly, the fly success message is pretty short.

It says deployment should be successful.

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

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

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

Yeah.

Um for a VPS, we have to answer that question.

Right, good.

So I haven't written that that success message yet.

Um, but I think for my my approach of Gunacorn Caddy as services, um, I did set up a git push.

Um so I think the I think the second deployment is make your changes, commit them, run git git push, and then I'm not quite sure how to restart the services.

Um and that's a a question, you know.

I'm not sure how much responsibility I'm gonna 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 I have felt like I'm standing in the shoes of the people who started all these pass providers by writing this serve product at SH and writing a script for it.

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

Um so I might just put a small script on their their server that says like, you know, run this SH command 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 gonna need to do to maintain it.

And opinions will form.

Yes.

Can I ask if you're going to I asked you?

Sorry, go ahead.

Well, I was uh Carlton saw this yesterday.

I I posted a question on Mastodon.

So I said the all the the pass focused plugins have two modes.

There's the automated automate all mode where it does everything for you, uh, including making your commits and pushing your project.

And it has a configuration only mode where it does a configuration, uh, which is the hard part.

Uh, you make the commit, which is easy, um, and you run the platform's deploy command, which is easy.

Uh, should be easy.

Um with a VPS, it's much I have really struggled to come up with a configuration only um 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, that's it's not at just one step for configuration.

It might be like, I I don't know if I want to do like manage.py deploy dash dash configure remote.

Manage.py dash dash uh configure local, manage.py dash dash push.

Um 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 re-re-create the entire CLI for Oku if you want.

Um 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.

If you give an example, that's that's sufficient.

I always felt with um VPS's there's sort of two steps.

Well, you 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 that 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 well, step zero before step one or after step one?

Right.

You know, with the with the past providers, it's very clear here's your local work, here's your remote work.

Yeah.

Uh with a 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.

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 pair of VPS.

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 or a docker, you know.

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 gonna 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, when you with the Heroku support, is that are you using the Git based or are you also using a Docker Docker kind of file thing with Django simple?

Yeah, for Heroku.

But the other ones you are are not, right?

You need to generate well, I mean, I guess that this has changed to be fair.

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

They were automating a little bit, but it's still ultimately like I would have you'd you need to, and maybe I'm dating myself, but you needed to um the yeah, the just the deployment was different.

Like you could git ignore some things and Heroku wouldn't have it, but like Fly would still see it unless you added a you know, uh Docker ignore um file.

And so, you know, it would create a Docker ign a Docker file for you, but if you didn't know to ignore it, then I just found all of that frustrating.

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.

Oh, 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.

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.

And so Django's simple deploy.

I've had one person criticize a product, and that was somebody who knows deployment way better than I do, and probably better than most of us.

Um, 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.

Um so uh Django 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.py deploy, dash-automate all if you want.

Um you'd probably do the configuration only so they make their commit and 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 left out.

Any deployment's complex, they just are.

Um, this is one of the problems.

But a deployment's 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 round 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.

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 apply pie, 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 deepen 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.

Um one of the reasons, okay, one pattern we see in platform's deployment docs is they give you a very simple Docker file.

They give you a very simple proc file or a very simple set of changes to make um 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, um, the more chances they have of a failed deployment.

And no platform wants people to fail their initial deployments because you'll walk away.

Um, if those files and changes are being made for you, being written for you and made for you, there's no need to simplify it.

And so when we're talking about a Docker-based uh deployment, uh I had this interaction with Jeff Triplet 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 Bonegartner's chamber of production.

Um, there are settings changes that he's making in that project that would be beneficial to a good number of people.

Um, and we can just dump those into the file because it doesn't matter if it's 30 of the lines of modified settings if you're not having to take tell people to type it or copy it or yeah.

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 uh in there might have 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 Django Python clearly just looking at it, it was completely unoptimized.

And so 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.

Without it up and running, it's difficult to see how these changes matter and and to even use them.

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

Um, but it, you know, nothing like learning on the job, right?

And nothing like learning on your own, your own project rather than taking down, you know, your company's uh servers by accident.

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

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

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

Um 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.

Um, it gives a place for people with expertise on both sides of this uh this world to share their learnings.

Which is

Like, you know, we as 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 sit see some things that you might not know otherwise.

Um kind of I was a little intimidated by uh thinking about how big the the plugin ecosystem might grow.

Um, but it really shouldn't.

Uh 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.

Um but we should be able to to basically formulate a good like gunnacorn caddy approach for VPS, a good Docker one, and that's separate from the Gunna Corn Caddy, but like the the VPS that I'm using, uh 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 gonna add is dash-sh db.

And so you can choose SQLite or Postgres.

Um, because that's just a a switch in the the configuration.

I don't want to put like DSD-VPS and there's a flag for whether you want to use Docker or uh Gunacorn.

Or or I shouldn't say that, because you can use that within Docker, but yeah,

I see your point.

Yeah.

Yeah.

Does that mean a question?

Because like command line flags are a bit of a pain to type, right?

I don't know.

It was literally just a I was dazing off into creative world.

I think I lean towards um CLI args because it's it's a constraint.

I know I don't want too many.

Uh whereas starting to find a config file, the whole goal originally was to you run a couple commands and your project is deployed.

So Yeah.

Because you can imagine things like S3 argue, you know, or values and uh a secret store and a DB that you need to connect to and a a Redis cluster that you you want for caching and simple deploy, the default plugins don't need to provide that.

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

Um, you know, what's simple?

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

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

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

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

Maintaining it might not be simple, but the initial deployment is 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, it's a lot easier to have something that works that you poke at.

Yes.

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.

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 um efficiently and effectively.

And so that's the same thing that keeps me in Django.

Um my work going forward is gonna be to continue to clean up this uh core plugin boundary for simple deploy, clean up the testing story.

Um 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 it's pretty interesting.

Um, but I also want to go back to my own Django projects.

Um I have a project focusing on math education, um, some projects about music and whatnot.

So Django works for me.

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

Um, 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.

Um I've occasionally run into some libraries.

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

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

So that the 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?

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

Um, 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 the founder.

So I think um the things I'm most excited about in Django is probably Django Not Space.

Um because seeing this steady stream of newer perspectives who already have their hands in the Django code base feels really good.

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

Well, we could keep keep talking for quite a while, but um, 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.

Bye bye.