Django Auto Forum - a car-enthusiast community on Heroku and S3

During Zip Code Wilmington cohort 3.1 in the summer of 2022, one question kept recurring: how do you give car people a place to talk that you actually control? Social feeds are fine for discovery, but they are terrible archives for how-tos, project threads, and long-form write-ups.

That became Django-Auto-Forum: a Django forum aimed at automotive enthusiasts, with cloud-backed uploads and enough structure to grow into profiles, projects, and a dev blog. The repo is public, still marked work-in-progress in places, and pinned on GitHub for a reason. It was the first full web application stack shipped end to end on this track, not just a homework script.

Project dossier (apps, deploy BOM, timeline): Django Auto Forum.

What the project aimed to build

The README pitch is simple: a website for car enthusiast how-tos. In practice that meant several cooperating Django apps:

• discuss_forum: threaded discussion and the core forum experience
• user_profile: accounts, identity, and (eventually) a garage-style profile concept
• projects: project pages separate from one-off posts
• blog: longer static announcements and advanced views
• forum_base: shared project wiring and early scaffolding

The feature list in the repo README reads like a product roadmap: comments, reactions, groups, private messages, image hosting to the cloud, and a front-end framework layer on top of server-rendered Django templates. Most of that stayed WIP. What did ship was the skeleton worth iterating on: auth, app boundaries, admin tooling, and deployment plumbing.

Stack and deployment choices

By early September 2022 the dependency list had grown into a credible production footprint (requirements.txt):

• Django 4.1 with PostgreSQL (psycopg2-binary, dj-database-url)
• Heroku deployment (django-heroku, gunicorn, whitenoise)
• AWS S3 media storage (boto3, django-storages): the README literally tracks adding storages and boto on 9/2
• django-crispy-forms, django-taggit, django-tinymce, django-hitcount, Pillow for uploads and rich content

That was the bootcamp lesson in miniature: Python is the language, but data, storage, and hosting are the job. Getting a forum to accept an image upload and persist it to S3 felt closer to real product work than another CSV exercise.

Heroku setup also appears separately in the repo (Heroku.md): environment variables, buildpack assumptions, and the kind of boring checklist you only appreciate after the first failed deploy.

What the build taught (the non-tutorial parts)

Monoliths are a feature at small scale

Splitting user_profile, discuss_forum, and projects into separate apps taught clear boundaries early. Even when everything runs in one Django process, clear app ownership keeps templates, URLs, and migrations from turning into soup.

Cloud storage is not an afterthought

Forums live or die on attachments: photos of installs, screenshots of tuning logs, PDFs of wiring diagrams. Wiring django-storages and boto3 before the UI polish forced early thinking about upload paths, bucket permissions, and what happens when a post is deleted but the object remains in S3.

Function-based views vs class-based views

The README to-do list includes migrating function-based views to class-based views. That was intentional debt. The capstone prioritized routes that worked over abstractions not yet trusted. That trade fit the timeline.

Automotive domain knowledge carried over

This was not a generic CRUD demo with fake data. The subject matter came from the same world as Formula SAE work and aftermarket R&D: people who measure twice because the second time might be on a lift at midnight. Building for that audience made the schema choices feel concrete: projects vs posts, profiles with a future garage section, tags that might follow platforms or mods.

Honest status

The repo README is candid: forum posting, subforums, and several interaction features were still WIP when active development paused. There are ~190 commits on main, plenty of iteration, but the repo would not qualify as production-ready community software. It is a foundation, not a finished product.

If you browse the github_img folder you can see early admin UI screenshots: enough to prove the apps hung together, not enough to claim victory over Discourse.

Epilogue: Django-Auto-Forum, stageastuff.com, and this site

Years later the problem statement has not changed. Only the tooling.

stageastuff.com is the current home for that thread of work: an automotive community brand built around Nissan Stagea culture and the kind of long-form, owned-content publishing that forums and project logs were always meant for. The domain is still early (placeholder landing page today), but the intent is continuous with Django-Auto-Forum: enthusiast how-tos, project archives, and a hub that is not rented from an algorithm.

Where Django-Auto-Forum was a Heroku monolith with S3 uploads and server-rendered templates, the present stack on heff.world (this site) looks different on paper (Astro, TypeScript, Keystatic, membership plumbing), yet the architecture rhymes:

The site build log notes that heff.world exists partly to re-link projects that outgrew a single landing page. stageastuff.com is one of those touchpoints: the spiritual successor to a forum started when the bootcamp asked for proof of cloud shipping. Django-Auto-Forum was the first cast; stageastuff is the nameplate for the next iteration; this site is the workshop where the tooling gets refined.

If you are maintaining an old Django repo and wondering whether it still matters: it does, as lineage. The URLs change, the frameworks change, but the goal (give car people a place they own) is the same one the project still pursues.

Repository: github.com/jjheffernan/Django-Auto-Forum.