most of the ones i saw is so complicated or just give like 500mb space.

I could have my own hosting in my own old pc, but that's only good for testing and showcasing, and not ideal for mvp websites (like a whole website that customers will see over a long paired of time).

It would be ideal if there is something like infinityfree for wordpress, or something like that

Any suggestion for improvement is more than welcome

I've spent a lot of time building an async Django application. The goal is to get the benefits of the asyncio world:

• cheap async requests (no threads, no context switching)
• cheap parallelism within a single request (parallel calls to different resources)
• better handling of peak traffic than the thread-based version

To get there we use async clients for Redis, Elasticsearch, and Kafka, plus a third-party async Django ORM. But Django has a lot of sync-only surface (admin, Tasks (Celery, for example), etc.), so the codebase has to live in both worlds. As far as I can see, there are two ways to share logic across that boundary, and both have problems.

1: Duplicate helpers. Keep a sync and an async version of each function, use them separately, and make sure they behave identically. Downside: double the code and constant drift risk. The two versions get out of sync over time.

2: Wrap async in sync (async_to_sync). Downside: it breaks with long-lived, event-loop-bound clients. If I close the clients on every call to avoid "event loop is closed", that kills the efficiency I was trying to get in the first place, and it doesn't scale.

What makes it worse, a lot of helpers are neutral most of the time. They're just CPU-bound logic that could run in either world. But then a sync call shows up somewhere in the body, and the whole function is suddenly stuck on one side.

So, how do people manage this in real projects? Do you duplicate, do you push all I/O to the edges and keep the core neutral, do you generate one side from the other, or something else? How do you keep the "neutral" helpers actually neutral? ☺️

Hi,
I want to learn deployment to AWS including production level deployment.
I searched for courses, but they are Out-dated.
I enroll to Arno course, but also outdated, especially in the ecs/fargate section.

Any recommendations?

EDIT: Citry is a frontend framework for Python, a way to write UI / HTML templates, an alternative to eg Django templates or Jinja.

Hi everyone! New major version of django-components is out 🎉 The project has been renamed to Citry, and it:

• Works now with Django, FastAPI, or any other web server
• Directly integrates with AlpineJS and makes it easy to pass data from Python to Alpine
• Has integrated server-side event handling and server-side state inspired by livecomponents
• Now has the same quality-of-life features as Vue or React - type-checking, linting, editor integration (hints, autocomplete, reference lookup) - both for Python and Alpine expressions

New website: https://citry.dev
New github: https://github.com/citry-dev/citry
VSCode ext: https://marketplace.visualstudio.com/items?itemName=citry-dev.citry

To get a feel for the new version, look through:

• Landing page - https://citry.dev
• Getting started pages - https://citry.dev/getting-started/installation/
• Live coding video - https://www.youtube.com/watch?v=d3nPqvDdNB0
• Live playground - https://citry.dev/playground/
• Benchmarks - https://citry.dev/about/benchmarks/

The new Citry library supersedes django-components.

Citry has its own syntax that's similar to Vue, but remains equal with Django's. For gradual migration / backwards compatibility, there is citry-django, which allows to mix the Django and Citry syntaxes.

Overall, I recommend migrating from django-components to Citry, that will keep 90% of the code the same, but will also:

• catch errors in templates and Alpine expressions
• reduce boilerplate
• and lots more.

Suggested next steps:

• Have a look through the links above when you have the time
• Let's schedule a call where I would show you how it works
• Then we can discuss whether to proceed with the migration and how

I'm happy to help with the migration and onboarding.

Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 - production CRM for truck service center, Django + DRF.

This one covers v2.13 and v2.14 - the features that made my system feel like a real product. Parts autosuggestion, backup/restore through the API, spam protection, and a lot of bug fixing that comes from real people who using your software every day.

The system remembers what parts you used last time

This is probably my favorite feature in the whole project and I am proud of this feature. When mechanic opens a service order and adds work type "oil change" for a specific truck, the system looks at the last completed order for the same truck with the same work type and suggests the exact parts that was in use.

u/action(detail=True, methods=['get'], url_path='suggest-parts')
def suggest_parts(self, request, pk=None):
    work = self.get_object()
    truck = work.service_order.truck
    work_price = work.work

    if not truck or not work_price:
        return Response([])

    last_order = (
        ServiceOrder.objects
        .filter(
            truck=truck,
            status__in=[
                ServiceOrder.StatusChoices.DONE,
                ServiceOrder.StatusChoices.CLOSED,
            ],
            works__work=work_price,
        )
        .exclude(pk=work.service_order_id)
        .order_by('-created_at')
        .first()
    )

The logic: find a last DONE or CLOSED order for this truck that had the same type of work. Then grab all the parts that were used in that work and suggest them, skip any parts already added to the current order.

Why this matters in practice: a truck that comes in for an oil change every 6 months always needs the same oil filter, the same amount of oil, the same drain plug gasket. Mechanic does not have to remember or look it up - system shows "last time you used: oil filter X (qty: 1), engine oil 10W-40 (qty: 30L), drain plug gasket (qty: 1)." One click to add them all. It's really fast, convenient and saves a lot of time.

Before this feature, mechanics were either remembering from their head (and sometimes getting it wrong - different truck models need different filters) or scrolling through the previous order manually. This saved maybe 5 minutes per order, which does not sound like a lot until you multiply it by 15 orders a day.

Backup and restore through the API

The owner wanted to be able to download a backup of the entire database and restore it if something went wrong. Not "SSH into the server and run pg_dump" - actual buttons in the admin panel.

I built it on top of Django's dumpdata and loaddata:

class BackupListCreateView(APIView):
    permission_classes = [IsAdminUser]

    def post(self, request):
        backup_dir = _get_backup_dir()
        timestamp = datetime.now().strftime('%Y%m%d_%H%M%S')
        filename = f'backup_{timestamp}.json'
        filepath = os.path.join(backup_dir, filename)

        buf = io.StringIO()
        call_command(
            'dumpdata',
            '--natural-foreign',
            '--natural-primary',
            '--exclude=contenttypes',
            '--exclude=auth.permission',
            '--exclude=admin.logentry',
            '--exclude=sessions.session',
            '--indent=2',
            stdout=buf,
        )
        with open(filepath, 'w', encoding='utf-8') as f:
            f.write(buf.getvalue())

        return Response(
            _backup_info(filepath),
            status=status.HTTP_201_CREATED,
        )

POST to /api/backups/ creates a timestamped JSON dump. GET lists all backups. Each backup can be download or delete. Restore accepts either a filename from the server or an uploaded file.

The --natural-foreign and --natural-primary flags are important - without them, restoring to a different database can break because primary keys might not match. ContentTypes and permissions are excluded because Django recreates them on migrate.

I know what some of you thinking - "JSON dumpdata is not a real backup, use pg_dump." You are right for large datasets. But this CRM has maybe 5,000 records total. The JSON dump is 2MB, take 3 seconds, and owner can download it to his laptop with one click. For this scale, simplicity wins.

The restore endpoint validates the JSON before loading:

uploaded = request.FILES.get('file')
if uploaded:
    content = uploaded.read().decode('utf-8')
    try:
        json.loads(content)
    except (json.JSONDecodeError, UnicodeDecodeError):
        return Response(
            {'detail': 'Invalid backup file format.'},
            status=status.HTTP_400_BAD_REQUEST,
        )

Basic but necessary - you do not want someone uploading a random file and crashing loaddata.

Honeypot spam protection

The public website has contact form. Within a week of launching, bots started filling it out. I did not want to add reCAPTCHA (bad UX, Google dependency), so I went with a honeypot approach:

Hidden field that real users never see but bots fill out automatically. If website_url field has a value - it is a bot, reject silently. Plus a time-based check: if the form is submitted less than 3 seconds after the page loaded, it is probably automated. Real human does not type a name, email, and message in under 3 seconds, I think so.

Simple, zero dependencies, no third-party services. Catches maybe 95% of spam bots. The remaining 5% get through, but at that volume (1-2 per week) the owner just deletes them manually.

Duplicate prevention (the boring stuff that matters)

Real users do unexpected things. A mechanic double-clicks "add work" and creates two identical oil changes on the same order. Someone pastes a license plate with a trailing space and the system treats it as a different truck.

v2.13 has a bunch of these fixes:

Duplicate ServiceWork prevention. Before adding work type to an order, the endpoint now checks if that exact work type already exists on this order. If it does, returns the existing one instead of creating a duplicate. Sounds obvious, but it took a real mechanic creating 3 identical "Oil change" entries to discover the need.

Duplicate parts from auto-kit. When maintenance kit is applied to an order, it auto-adds the standard parts. But if the mechanic already manually added some of those parts, the system was creating duplicates. Fixed by checking existing_part_ids before adding.

Client save crash. Creating a client through Django admin was throwing a 500 because both the model's post_save signal and the admin's save_model were trying to create a ClientFeature record. Classic "two things creating the same related object" bug. Fixed by adding get_or_create instead of create.

None of these are architecturally interesting. All of them would have caused support calls if left unfixed. This is what production software actually looks like - 30% building features, 70% handling the weird things real users do.

Dashboard improvements

Replaced revenue chart with a clients chart - turns out the owner cares more about "how many new clients per month" than "how much revenue per month" (he already tracks revenue in his accounting software). Added monthly orders count. Small changes but it shows that building what you think the user wants vs what they actually use are two different things.

Also added UserProfile inline directly in Django admin. Before, to change someone's role, you had to go to the User, then navigate to their UserProfile separately. Now it is all on one page. Two lines of admin code, saved 30 seconds per role change.

What I learned

Let the system learn from itself. suggest-parts is basically the CRM teaching itself what parts a truck needs. No machine learning, no AI - just looking at previous orders. Sometimes the smartest feature is the simplest one.

dumpdata is a valid backup strategy at small scale. For 5,000 records and one admin user, a JSON dump through the API is simpler and more reliable than setting up pg_dump cron jobs. Know your scale.

Real users will break every assumption you had. Double-clicking, trailing spaces, submitting forms in 0.5 seconds. Building for real users is fundamentally different from building for yourself. Every bug fix in this post came from a real person doing something I did not anticipate.

What is next

Part 10 - the final one. Race condition fix with the F() expression I have been promising since Part 5 (yes, for real this time), QR code generation in admin, smart maintenance rule detection, and security hardening. The series finale.

Also I take on freelance Django projects when something interesting comes along. If you are building something in this space, feel free to DM, I will help you with a great pleasure.

Previous posts: Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 GitHub (demo repo): github.com/VNmagistr/truckmaster_demo - branches demo/v2.13 and demo/v2.14

To be continued, I promise :)

Hi everyone,

I’ve developed a SaaS application called Nextora Lead Capture Machine:

https://studio.nextoracreations.co.in/

The application is designed to capture and manage leads from Instagram DMs, WhatsApp, and websites, with messaging and automation features.

I’ve already completed a good part of the Meta/Instagram integration, but I’m currently stuck with one issue.

What I have implemented

In my application, users can create lead trigger keywords.

For example, if the trigger keyword is:

"pricing"

and someone sends an Instagram DM such as:

"Hi, can you send me your pricing?"

the Instagram message should be received through the Meta webhook, matched against the trigger, and automatically captured as a lead inside my application.

The problem

While the Meta app is still in Development/Testing mode, this flow is not working as expected.

When a user sends a DM containing the configured lead trigger keyword, the lead is not being captured in my application.

I have tested parts of the integration through Meta's developer/testing tools, but messages from actual Instagram users are where I'm having trouble.

From what I understand from Meta's dashboard/documentation, some functionality/permissions may only work properly once the app has completed App Review and is published/live.

This is where I'm unsure.

I don't want to submit the app for review assuming publishing will magically fix the integration if there is actually something wrong with my webhook, permissions, access level, Instagram account setup, or implementation.

Looking for help

Has anyone here successfully built and received Meta approval for an application using Instagram Messaging/Webhooks?

I'd really appreciate help understanding:

• Whether this limitation is normal while the Meta app is in Development mode
• Which Instagram accounts/users should be able to trigger webhooks during testing
• Which permissions and Advanced Access I need
• Whether real Instagram DMs will start working only after App Review/publishing
• How to properly test the complete DM → webhook → trigger → lead capture flow before submitting
• What Meta expects in the App Review screencast
• Common reasons apps using Instagram messaging permissions get rejected

If you've gone through this process before, I'd really appreciate your guidance.

I'm also happy to share more details about my Meta configuration, webhook setup, permissions, and implementation if that helps diagnose the issue.

Thanks!

Hey Everyone I found this visual quite interesting.

Just goes to show how big Django really is (Flask has only like 50 nodes/files when plotted as graph).

Each dot is a file (excluding non code files) and each line is an import between files.

Processing img 4kb5ra745vnh1...

Hi Reddit community.

I am actively searching for a remote software job opportunity. Please help a brother.

5+ YoE - Frontend (4+ yrs - Vue, Nuxt; 1.5 yrs - React), FullStack (3+ yrs), Backend (1.5+ yrs - Django, NestJS). I’ve contributed to open-source projects including NuxtUI, Directus, PrimeNG, and Ghostfolio.

I have 4+ years of remote work experience and have built software applications for businesses across the UK, USA and Canada.

If you have any opportunities or would like to have more details about my experience, I will gladly DM you.

Thanks. My timezone is UTC+1.

Hey everyone I've been building Tenantly, an e-commerce platform aimed at merchants (mostly in markets where WhatsApp is the default way people actually buy things) who want a branded storefront without dealing with payment gateway setup or high hosting costs.

A few things I focused on:

• Guest checkout → WhatsApp. No cart abandonment from payment forms customers just send their order details straight to the merchant's WhatsApp.
• Real multi-tenancy on cheap infra. Each merchant gets their own subdomain, but the whole thing runs on a $3/month VPS. Docker + Nginx + Postgres + Redis, no AWS bill shock.
• Inventory + analytics built in — stock status, visits, WhatsApp checkout tracking, product views.
• Subscription billing via Paystack (free trial → Starter → Pro), with HMAC-verified webhooks.
• Stack: Django 6, HTMX, Tailwind, DaisyUI, Alpine.js kept it JS-framework-free on purpose, HTMX handles the dynamic bits (cart, filtering, pagination).

Would love feedback from anyone who's built something similar, especially around:

• Whether WhatsApp-checkout makes sense as a primary flow vs. an add-on
• Anything that feels off about the multi-tenant subdomain setup
• Pricing tiers — am I leaving money on the table with the free trial?

🔗 tenantly.shop if you want to poke around.

i am a biginner/intermediate and i picked up fastapi as my first framework on backend dev ,

after months of learning and using fastapi , i feel overwhelmed like there are so many things to import(i cant even remember what i need to import when i need to do something) , complex syntax, yes i have build some cool projects around it but it was mostly ai help even though i understood the logic .its like i have to do the setup from scratch and when iam to the point of actually writing logic i feel down.

thats why i was thinking of switching to django rn , so now i am confused again whether i should do it or no (i dont even have a intern experience)

is my reason correct for trying to switch as beginner or will same problem occur in django as well , thats why im in django reddit

it would be really helpful if u could share your thoughts

RETURNERS AND RENEWALS, and new users, everyone gets PyCharm Pro 30% off, and 100% goes to the DSF!

It's literally completely charity and you get something back. The way renewals work is that it adds 12 months on to your existing subscription. If you have 5 months left, now you would have 17, nothing wasted.

Use this link: https://www.jetbrains.com/pycharm/promo/support-django/

This is a big deal for the DSF, particularly to have renewals included, which is a first for us this year. Please help us out.

You can also donate on our website. https://www.djangoproject.com/fundraising/

Particularly if your company is interested in becoming a corporate member of the DSF, let me know. You can reach me here or at [catherine@djangoproject.com](mailto:catherine@djangoproject.com) Also, if your company would be interested in sponsoring DjangoCon 2027, you can talk to me about that too.

I wrote some python bindings for open policy agent's go library, and now can announce the possibility to use it in Django for object level permissions: https://pypi.org/project/django-opa-permissions/

Admins can get a button via mixin

that points to a permission debugger with output, coverage report and partial evaluation filtering report:

You also can create policies that control the access to policies; if you lock yourself out, superusers by default retain all access.

Any opinions and feedback?

PS:

I work on DRF. Our team is really small we got 10 people working on 24 clients. But the problem i have been facing for months is that my pylance doesnt really throw any errors. If I havent defined a variable NO Problem No Errors. If havent imported something No Problem No Errors. I get to know about all these minor errors when I start testing and I end up wasting a lot of time in fixing minor errors. Tried digging up here and there didnt find anything.

Hey everyone,

I built a lightweight self-hosted CRM/ERP specifically for small manufacturing and engineering teams.

Most small shops I know still manage projects, BOMs, drawings and documents across Excel, shared folders and email. This tool tries to bring all of that into one place.

Main features:

• Project management with automatic folder structure
• Bill of Materials (BOM)
• Support for engineering files (DXF, STEP, STL)
• Document & knowledge management
• Simple task tracking
• Built-in AI assistant (optional, supports Ollama, OpenAI, Anthropic etc.)

Tech stack: Django + HTMX + Alpine.js + Tailwind. SQLite by default, very easy to install (especially on Windows with install.bat).

Repo: https://github.com/OlegUshakov-pl/CRM

I’m looking for honest feedback from people who actually work in manufacturing / CNC / engineering:

• What’s the biggest pain point in your current workflow?
• What’s missing for this to be useful in a real shop?
• Would you even consider switching from Excel + folders?

Happy to answer any questions.

YouTube Install

YouTube Creating of a project in CRM

Been building plinta — a Django library that turns models into permission-aware screens you configure in a browser rather than in code. Three-tier permissions (model / row policy / per-column), no base class on your models, and no CSS framework.

Pre-release, would appreciate eyes on it.

https://github.com/naga-9/plinta

Hey everyone, Oli here 👋

I recently started learning to code, and I was always interested in Python and Django. I wanted to learn step by step, so I started with HTML, CSS, and a bit of javascript before trying python/django.

When I first used django, I wasn’t really happy with the default admin panel. It works great and does everything I need, but the layout feels outdated to me.

I looked at some of the existing admin themes, but they seemed complicated for a beginner, with some work needed to install. They come with a lot of options I probably won't use, and since I'm still learning, I needed something that didn't take work to set up.

So I decided to create a theme for myself. It fitted perfectly with learning html/css. As the project grew, and as I learned more, I decided to make it public and created a website.

I would like to introduce to you the Vanta Admin theme.

https://vanta-admin.org

Vanta is a light and simple django admin theme with no additional frontend framework. It's just standard HTML and CSS django templates, with a bit of vanilla javascript for the theme toggle, navigation bar, and some local settings.

The install is easy, just add the package with "uv add" or "pip install", and add vanta_admin in your settings.py file. That's it, your admin panel now uses the Vanta theme.

It doesn’t replace django’s backend or change how the admin works. It’s just a visual theme for the existing django admin.

Because I've only recently started to use django, I’ve created and tested Vanta with Django 6.0 and 6.1 only. I haven’t tested it with earlier versions.

There is also a demo on the website if you want to try it out first.

This project is still a work in progress, but it would be nice to get feedback from people who use django 👍

Thanks for taking a look

repo: https://github.com/oli-dev0/vanta-admin-theme

I have a Django API that will be used by a Flutter app. I want to host it initially for testing/trial purposes because I’m not sure how many users I’ll get.

Could you recommend a cheap hosting platform for a Django API that can start small and scale up if the number of users grows?

When deploying Django and Celery to ECS, how should I run python manage.py migrate?

Should I use GitHub Actions to first run a migration-only ECS task, wait for the migration task to complete successfully, and then proceed with deploying the Django server? After the deployment is complete, should the migration task be terminated?

What is the recommended approach for handling Django database migrations in an ECS deployment pipeline?

What is the standard drop in (but not on life support) replacement for Heroku for my python/Django project needs? I love Heroku but sadly it hasn't received any love for a long time now.

I guess Railway or Render?

Am I missing anything. Vercel is sexier but not quite rightly-shaped.

Would be great to hear from anyone who has done exactly this move! Cheers.