A modern foundation for self-hosted vehicle marketplaces
Self-hosted vehicle marketplace platform
AutoCore brings the public marketplace, dealer operations, administration, APIs, search, media processing, installation, and lifecycle operations into one configurable system.
Commercial distribution is being prepared.
At a glance
Category
Software Product / Automotive Marketplace
Type
Self-hosted marketplace platform
Version
1.0.0-rc.1 · Release Candidate
Status
Commercial Release Candidate
Year
2026
Role
Product design, architecture, development, operations
Overview
What AutoCore is
AutoCore is a vehicle marketplace platform that an operator installs and runs on their own infrastructure. It is not a hosted service and not a template: it is a complete system with a public marketplace, a dealer and seller model, an administration surface, a versioned API, background processing, and the installation and lifecycle tooling needed to keep an instance running.
The product exists because building a credible vehicle marketplace repeatedly means rebuilding the same foundations — catalog structure, listing states, moderation, media handling, search projection, and the legal and consent records a real marketplace needs. AutoCore packages those foundations as a configurable core rather than a one-off build.
It is aimed at marketplace operators, agencies delivering a marketplace for a client, and technical teams who want to own their data and deployment rather than rent them.
Origin
The engineering objective
The starting constraint was that nothing about a single city or country should be hardcoded. Currency, locale, timezone, distance units, address and phone formatting, and the location hierarchy are configuration, not assumptions baked into the code.
The second constraint was that the platform should be able to produce branded editions from one canonical source. EskişehirAraba was built from that same core, which forced the branding, localization, and market boundaries to be genuinely separable rather than theoretical.
The third was operational clarity: each installation serves one primary market. That is a deliberate boundary. It keeps pricing, units, moderation, and legal policy unambiguous, and it avoids shipping a half-finished multi-market abstraction that would complicate every query and every screen.
Engineering outcomes
Verified at release-candidate stage
Each figure was re-derived from the release-candidate source rather than carried over from earlier notes.
- 4Application surfacesWeb, Admin, API, Worker
- 59API controller classesGrouped by business domain
- 403Endpoint methodsSource-audited across 59 controllers
- 85Public OpenAPI pathsSanitized public artifact
- 56Public OpenAPI schemasShared request and response shapes
- 264Documentation pagesPublished product documentation
- 34Database migrationsVersioned schema history
- 1Primary market per installationA deliberate operational boundary
Capabilities
What the platform covers
Search and filtering
Faceted search over listings with brand, model, price, year, mileage, fuel type, and transmission filters.
Vehicle catalog
Categories, brands, models, generations, and trims with structured equipment and lookup attributes.
Listing lifecycle
Eight explicit listing states from draft through moderation to archive, each with defined visibility.
Users and sellers
Individual sellers and dealer organizations with roles, permissions, and resource ownership.
Dealers and memberships
Dealer profiles, member roles, verification states, and storefront pages.
Moderation
Review queues for listings and reports, with recorded decisions and audit history.
Media processing
Background image processing with derived variants, checksums, and explicit processing states.
Legal and consent
Versioned policy revisions, acceptance records, and consent receipts kept as first-class data.
Payment readiness
Provider configuration, verification state, and webhook handling — inactive until explicitly enabled.
System health
Operational surfaces for installation status, background processing, and search health.
Public marketplace
The buyer-facing experience
The public surface handles discovery, comparison, and contact. Formatting follows the configured market, so prices, distances, and locations read correctly for the installation.
The demo runs on synthetic sample data.
Sellers and dealers
Two seller models, one listing model
Individual sellers and dealer organizations share the same listing pipeline. What differs is ownership, membership, and the storefront a dealer gets.
Administration
Operating the marketplace
Administration is a separate application with its own surfaces for the people running the marketplace day to day.
- User and dealer management with role and permission assignment.
- Vehicle catalog management: categories, brands, models, and trims.
- Listing moderation queue and decision history.
- Media review and processing-state visibility.
- Search operations and reindexing.
- Legal Center, Consent Center, and Payment Center surfaces.
- Audit history and system health.
Market model
One primary market per installation
The market is configuration. The boundary is deliberate.
- Country, region, and city define where the marketplace operates.
- Locale and currency drive formatting and pricing presentation.
- Timezone and distance unit (km or mi) are configured per installation.
- Address and phone formatting follow configurable presets.
- Market vehicle capabilities decide which categories are offered.
- Austin is the demo preset; Berlin was used to validate a non-US installation; Eskişehir is a materialized edition.
Catalog and lifecycle
From draft to archive
Every listing moves through explicit states, and each state determines search visibility.
- draft — created but not submitted
- pending_review — awaiting moderation
- active — publicly visible and searchable
- reserved — held for a buyer
- sold — closed as sold
- expired — past its active window
- rejected — declined in moderation
- archived — withdrawn from the marketplace
Media and search
Authoritative state, derived projection
Search and media are built so that neither can quietly become the system of record.
- PostgreSQL is the authoritative transactional store for every business record.
- Meilisearch holds a derived projection of listing data used for search.
- Redis supports transient coordination and background processing.
- Media assets record ownership, dimensions, checksums, and derived variants.
- Image processing runs in the Worker, outside the request path.
- Search state can be rebuilt from PostgreSQL; it is never the source of truth.
Legal, consent, payments
Recorded, not assumed
These capabilities give an operator the records they need. They are tooling, not compliance.
- Policies are stored as versioned revisions with an explicit publication step.
- Acceptance records link a user to the exact policy revision they accepted.
- Consent receipts separate necessary processing from optional processing.
- Payment providers are configured per installation and disabled by default.
- Provider configuration carries an explicit verification state.
- Webhook handling records processing status rather than assuming success.
These features do not constitute legal certification and do not automatically activate payment providers. Policy content, regulatory obligations, and provider agreements remain the operator's responsibility.
Architecture
Four surfaces, clear boundaries
Web and Admin are clients. The API owns business logic and PostgreSQL state. The Worker handles bounded background jobs.
Technology
The stack in use
Frontend
- Next.js
- React
- TypeScript
- Tailwind CSS
- shadcn/ui
- TanStack Query
- React Hook Form
- Zod
Backend
- NestJS
- TypeScript
- Prisma
- PostgreSQL
- Redis
- Meilisearch
Infrastructure
- Docker
- Nginx
- Cloudflare
- GitHub Actions
- Immutable release artifacts
Quality
- Vitest
- Playwright
- Accessibility testing
- Contract validation
- Dependency audits
API
API-first, with a sanitized public contract
Clients are consumers of a versioned contract, and the published artifact is a filtered view of it.
- Business logic lives in the API; Web and Admin are clients of the same versioned contract.
- Authentication and permission checks are enforced at the API boundary.
- Resource ownership is verified per request, not inferred from the client.
- Responses use a consistent error envelope and request identifiers.
- List endpoints share a common pagination contract.
- The published OpenAPI artifact is sanitized: operator-sensitive and internal-only routes are excluded.
- The 403 audited handler methods span every visibility class; the sanitized public artifact publishes 85 paths.
Installation
Installing and operating an instance
Installation is treated as a product surface, not a README.
- A guided installer with preflight checks before anything is written.
- Installation locking so a second run cannot corrupt a partial install.
- Idempotent steps that can be safely re-entered after an interruption.
- First administrator creation and primary-market initialization.
- An installation manifest recording what was installed and when.
- doctor, status, upgrade, and backup verification commands for ongoing operation.
Reliability
Security and operational boundaries
Stated as boundaries that are actually enforced, rather than as adjectives.
- Role and permission enforcement at the API boundary.
- Resource ownership checks on every scoped operation.
- Secrets are referenced by environment, never committed to source.
- Releases reference immutable image digests rather than mutable tags.
- Manifests and checksums establish artifact lineage.
- Backups are verified rather than assumed.
Documentation
Documentation as part of the product
The documentation was written against the release-candidate source and validated against the published routes. It covers installation, administration, operations, troubleshooting, security, and recovery.
Product
The product in use
Editions
EskişehirAraba, built from the same core
EskişehirAraba is a materialized marketplace edition produced from the AutoCore core. It validated branding, localization, market configuration, and operational separation in a live setting. It does not mean the platform is limited to one city or one country.
Status
Where the product stands
- Version
- 1.0.0-rc.1
- Status
- Commercial Release Candidate
- Deployment
- Self-hosted
- Primary market
- One per installation
- Native mobile app
- Not included
- Payments
- Integration-ready, disabled by default
- Commercial distribution
- In preparation
Explore
Explore the system
The demo, the documentation, and the public API contract are all open to review.
Commercial distribution is being prepared.