> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opslane.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Supported Stacks and Frameworks for Opslane

> Opslane works with any app that runs in a browser — React, Next.js, Vue, Rails, Django, and more. No SDK, no config, just a URL to your running app.

Opslane is framework-agnostic. Because it tests your app by opening it in a real browser — exactly the way a user would — it works with any technology that produces a browser-accessible interface. You don't install a library, add a configuration file, or change a single line of your application code.

## What Opslane needs

The only thing Opslane requires is a **URL to your running application**. This is typically a preview deployment that's automatically created when you open a pull request. Opslane navigates to that URL, interacts with the app, and checks for regressions.

<Note>
  Opslane does not need access to your source code, build pipeline, or infrastructure. If a browser can load it, Opslane can test it.
</Note>

## Confirmed frameworks

Opslane has been tested and confirmed working with the following frameworks and stacks. This is not an exhaustive list — if your stack runs in a browser, it works.

### Frontend frameworks

<CardGroup cols={3}>
  <Card title="React" icon="react">
    Create React App, Vite, and custom setups. Works with any state management library.
  </Card>

  <Card title="Next.js" icon="n">
    App Router and Pages Router. Works with static exports and server-rendered apps.
  </Card>

  <Card title="Vue" icon="vuejs">
    Vue 2 and Vue 3. Nuxt apps are supported as well.
  </Card>

  <Card title="Svelte" icon="s">
    Svelte and SvelteKit apps, including server-rendered routes.
  </Card>

  <Card title="Angular" icon="a">
    Angular CLI projects and standalone component setups.
  </Card>

  <Card title="Any other frontend" icon="globe">
    Remix, Astro, Solid, Qwik, Ember — if it loads in a browser, it's supported.
  </Card>
</CardGroup>

### Backend-rendered frameworks

<CardGroup cols={3}>
  <Card title="Ruby on Rails" icon="gem">
    Standard Rails apps with ERB, Hotwire/Turbo, and Stimulus setups.
  </Card>

  <Card title="Django" icon="python">
    Django with Django Templates or any frontend layer served from the same app.
  </Card>

  <Card title="Flask" icon="flask">
    Flask apps with Jinja2 templates or a decoupled frontend.
  </Card>

  <Card title="Laravel" icon="l">
    Laravel with Blade templates, Livewire, or a separate frontend.
  </Card>

  <Card title="Other backends" icon="server">
    Express, FastAPI, Spring Boot, Phoenix — any backend that serves a browser UI.
  </Card>
</CardGroup>

## Preview deployment platforms

Opslane works best when paired with a platform that automatically creates a preview deployment for each pull request. When a new PR is opened, the platform deploys the branch to a unique URL, and Opslane uses that URL as the test target.

<CardGroup cols={3}>
  <Card title="Vercel" icon="triangle">
    Opslane reads the Vercel preview URL from the PR deployment status automatically.
  </Card>

  <Card title="Netlify" icon="n">
    Netlify deploy previews are supported out of the box.
  </Card>

  <Card title="Railway" icon="train">
    Railway preview environments provide a stable URL per branch.
  </Card>

  <Card title="Render" icon="r">
    Render preview environments work with Opslane without extra configuration.
  </Card>

  <Card title="Fly.io" icon="plane">
    Fly.io apps with per-branch deployments are supported.
  </Card>

  <Card title="Other platforms" icon="cloud">
    Any platform that exposes a public HTTPS URL per pull request will work.
  </Card>
</CardGroup>

<Tip>
  If your preview platform isn't listed above, check whether it creates a publicly accessible URL for each PR. If it does, Opslane can use it. You can configure a custom deployment URL pattern in your Opslane dashboard settings.
</Tip>

## No SDK or library required

Unlike some testing tools, Opslane requires zero changes to your application:

* No SDK to install
* No `<script>` tag to add
* No test IDs or data attributes to add to your markup
* No environment variables to set in your app
* No CI workflow files to write

Opslane connects at the network and browser layer — entirely external to your codebase. Your application has no knowledge that it's being tested.

## Internal or private apps

If your preview deployment is behind authentication or a private network, Opslane will need a way to reach it. Options include:

* **Bypassing auth for the Opslane bot** using a shared test account or a feature flag that disables auth for specific environments
* **Tunneling** to make a local or VPN-protected app accessible to Opslane's runners

<Info>
  Support for private networking and tunnel-based access is on the Opslane roadmap. [Follow the open source repo](https://github.com/opslane/verify) for updates.
</Info>