GrowLyst is my project that helps plant growers manage their grows. It’s aimed at enthusiasts who want a better way to log their plants progress, track changes, and maybe learn from their own growing history.
In this article, I’ll walk you through how I set up the server structure to run GrowLyst. Keep in mind, this is still pre-production and things might change as I go along. It’s also my first real project so I’m expecting a few mistakes along the way.
Django Link to heading
The first big decision was which web framework to use. I knew I wanted Python, and Django quickly became the frontrunner. It’s one of the two major Python frameworks (the other being Flask), but what pushed me toward Django was that it already comes with many features you’d probably end up adding to Flask yourself (things like authentication, admin tools, and a solid ORM). For a first serious project, I wanted to play it safe and spend more time building features than wiring together basic infrastructure. The only drawback I’ve noticed is that Django can be a bit slow, but my plan is to focus on getting features done first and then optimize performance before release.
Celery Link to heading
Once the framework was set, I knew I’d need something to handle background tasks like sending notifications or processing data without slowing down the app. Celery was an easy choice since it integrates nicely with Django. I’m using Redis as the message broker, and honestly, one of the big reasons I went with this setup was that Render had a step-by-step tutorial for it. It made the whole process way easier.
GitHub Link to heading
Version control was a no-brainer. I’ve used GitHub before, and it’s both reliable and free for my needs. It also connects seamlessly with Render, which makes deployment smooth. I’m not the biggest fan of GitHub’s “Projects” feature though. While I actually prefer the workflow in AzureDevops (which we use at my full-time-job) I didn’t want to set this up or even pay for it. Another option would have been self hosting a service like Jjenkins. But I sat up Jenkins in the past for a homework assignment and it just is too much work if you want to bring a project to life fast. I dont regret going with GitHub at all. Just using the services I use now is allready enough work on it’s own and constantly moves my focus away from developing the app it’s actually about.
PostgreSQL Link to heading
The database choice was just as straightforward. PostgreSQL integrates perfectly with Django, is easy to spin up on Render, and has a rock-solid reputation for reliability. Add great documentation on top, and there was no reason to look elsewhere.
Flutter Link to heading
For the mobile side of things, I’m planning to use Flutter. It lets me build apps for both Android and iOS from a single codebase, which is a huge time saver. I haven’t started the mobile app yet, and I might even outsource it, allthough I am not really fond of this idea and it is way to expensive anyways. I know that I also just could have skipped using Django and could have gone developing a multi-platfrom-app with flutter right away. That said, part of the reason I went with Django for the backend is simply because I wanted to learn it. And in the end the time loss isn’t to big anyways because when using my webservices api the processing will happen on the backend servers anyways. So the mobile apps will be very fronted focused.
Render Link to heading
Finally, everything needs to live somewhere, and that’s where Render comes in. It’s modern, easy to use, and not overloaded with endless settings and menus. For image storage, I’m using AWS S3 buckets. That part was a bit of a learning curve, but once set up, it’s been smooth. Render might not have as many features as AWS or other big cloud providers, but it has everything I need, and deploying directly from GitHub is incredibly simple.
Hugo Link to heading
Hugo is a tool to quickly create static websites. This very website you are currently on was also build using Hugo. The qorkflow is really simple and the free to use templates look really good. That is why I will use it to build the static page which will contain GrowLysts documentation and istructions.
Wrapping Up Link to heading
That’s the current tech stack and setup for GrowLyst. Since this is still pre-production, things might change as I get closer to launch, especially around performance tuning and mobile development. For now, the goal is to keep building, keep learning, and get to a point where GrowLyst is something plant enthusiasts (including me) can really rely on.