Support and Services
VextJS stays Apache-2.0 and its public documentation stays open. Teams that need help applying the framework in a production context can begin a scoped conversation with the maintainers through GitHub Discussions.
Choose an entry point
For common troubleshooting, start with Error handling, Frontend troubleshooting, or Deployment.
Suitable engagements
- Architecture and launch review — assess routing, adapter selection, validation, OpenAPI, cache, security, deployment, and frontend boundaries before a production launch.
- Migration and integration sprint — plan or pair on a migration from an existing Node.js service, an adapter integration, or a React frontend adoption without introducing a second routing model.
- Team enablement and incident readiness — establish project conventions, test strategy, build/deploy checks, and a practical runbook for the Vext runtime.
Start a useful conversation
Open a discussion with the VextJS version, Node.js version, adapter, deployment shape, and the outcome you need. Do not post credentials, customer data, or production secrets. Add the operating system, minimal reproduction, expected and actual results, and checks already run when relevant. Discuss scope before agreeing whether to proceed and through which channel; a public post does not mean a service request has been accepted.
Clear boundaries
This page is an entry point, not a public price list or service-level agreement. Availability, scope, fee, timeline, response terms, and any private communication channel are agreed before an engagement starts. A support conversation does not change VextJS's public API, license, or supported frontend boundaries.
For product boundaries before a review, read Frontend Boundaries and Roadmap and Deployment.