Help & Business Inquiries



How can I reach out for help?


  • Discord to get help from the community.

    There aren't any rules and you can post what you want. That said, questions sometime don't get any answers on Discord, so we recommend reading the help guide to increase your chance of receiving valuable assistance (see the channel #help-guide). And consider giving back by helping others!

  • GitHub Discussions to get help from the Vike team.

    On GitHub if you follow these rules then you'll always get a response from the Vike team.

  • GitHub Issues to report a bug or request a feature.

How can I reach out for business inquiries?

Contact brillout:

Don't reach out on Twitter as it has shown to be unreliable.

Don't privately contact brillout for getting help unless you're a sponsor, see How can I reach out for help?

I can't achieve what I want, can I get help?

Yes, and you can use GitHub Discussions to get help from the Vike team, see How can I reach out for help?

If it turns out that your issue is caused by a Vike flaw, we will consider it a blocker on Vike's side and prioritize resolving it accordingly.

In general, Vike aims to be highly flexible and resolving blockers is important to us, ideally by design and at the very least by providing help.

Can I use Vike in production?

Yes. Many companies, from small startups to large corporations, are using Vike in production in a wide range of scenarios.

Consider, for example, the use case of some of Vike sponsors:

  • Alignable (social network), using a bespoke React integration with their Ruby on Rails backend. (Sponsoring brillout, the creator of Vike.)
  • Contra (freelance market), large codebase (>150 routes) with a bespoke React rendering strategy and GraphQL integration using Relay. (Sponsoring brillout.)
  • Ecosia (search engine), migrating their entire frontend from Nuxt to Vike for a substantial performance increase. (Sponsoring vikejs.)
  • Burda (publishing house with online newspapers reaching half of the German population), migrating their fragmented tech stacks of multiple and diverse online newspapers into one unified bespoke framework using Vike and Solid. (Sponsoring brillout.)

Can I use Vike to achieve what I want?

Vike prides itself on being a highly adaptable frontend framework. See for example the use case of some of Vike sponsors.

Vike supports all common use cases:

A common source of blockers are bugs; Vike is also unique because we quickly fix bugs and, to this date, we have been able to fix all bugs. We value clean abstractions and correctness, which significantly reduces potential bugs.

Beyond common use cases, Vike has been designed from the ground up to be flexible, so that it can fit special needs. You can use Vike to Build Your Own Framework.

If you have a use case you aren't sure you can implement with Vike then feel free to reach out.

In general, Vike aims to be as less blocking as possible. If you run into a blocker then don't hesitate to reach out.

Will Vike survive?

We are a group of passionate developers; working on Vike is the thrill of a lifetime and there is no reason for us to stop.

We're making significant progress on being able to financially sustain ourselfes.

Without relying on investor money, but through sponsorships and upcoming innovative open source business models. Independence is paramount for keeping Vike a community-driven project with transparent interests that are well aligned with its users.

As a company, you can secure Vike's future by sponsoring.

How can I contribute/support Vike?

Contributions in forms of code or sponsoring are much welcome.

What are these cryptic JavaScript errors?

Many cryptic errors come from CJS/ESM issues around npm packages that contain invalid JavaScript code, see workaround at Broken npm package.

We meticulously care about crafting error messages that are helpful, but we don't control the error messages coming from other tools.

Why is CSS leaked to other pages?

With Client Routing, when navigating from one page to another, the CSS of the previous page isn't removed. This means that any CSS loaded by the previous page will also apply to the next page. In other words: CSS cumulates upon page navigation.

For example:

// /pages/terms/+Page.jsx
import './style.css'
export const Page = () => (
  <div id="#terms">
    <h1>Terms of Service</h1>
      {/* ... */}
/* /pages/terms/style.css */
/* ❌ Bad: the CSS selector `section` can apply to any page */
section {
  font-size: 0.8em;

Narrow down the CSS selector instead:

/* /pages/terms/style.css */
/* ✅ Good: the CSS selector `#terms section` only applies to our terms page */
#terms section {
  font-size: 0.8em;

If you use Vue with .vue files, then Vue already scopes the CSS for you: the CSS you define in a .vue file is guaranteed to apply only to the component defined in that .vue file.

If you use React or Solid, then we recommend using inline styles and/or a CSS-in-JS library (or Tailwind), while minimizing CSS files. Inline style aren't global and, therefore, aren't leaky.

CSS is injected by Vite in the form of <style> tags. If you're curious why Vite doesn't remove old <style> tags, consider that removing CSS is problematic during the transient state upon page navigation. (It would lead to FOUC because there is no transaction primitive for DOM manipulation.) In general, regardless of Vite's behavior, it's a good practice to narrow down CSS selectors.

Why are there a lot of HTTP requests in dev?

In development, you may observe a lot of HTTP requests fetching many JavaScript files. That's because Vite does lazy transpiling.

While it's true that doing a lot of HTTP requests slows down page load (and optimizing that aspect is on Vite's radar), Vite's lazy transpiling approach enables unparalleled development speed.