Start with one local project. Unlock the full workflow when you need it.

Install and open Decker, then scan a local folder before you sign in. Decker asks you to confirm your account only when you save the project.

1. Select your saved project in the sidebar.
2. Press Play next to a service to start it.
3. Wait for the status indicator to turn green.
4. Use Stop or project-level controls when you are done.

Each browser service gets a local URL through Decker's proxy. Approved Simple Local URLs omit the port; otherwise Decker shows the proxy's actual runtime port. Click the URL badge to open it.

http://service.project.localhost http://service.project.localhost:1456

With frameworks like Next.js, Vite, or Nuxt, code changes often appear without refreshing. Backend frameworks may need a manual refresh.

Logs help you prove that the local project is really running. Open the Logs panel below the service row to see server output in real time.

• Check install errors and missing dependencies.
• Inspect framework output from the running dev server.
• Restart the service after fixing project files.

Framework support applies before payment because Starter users need to know whether their first local project can run.

A paid membership removes the one-project Starter limit, so Decker can keep multiple independent client apps and experiments at the same time.

A valid repository or workspace is one saved project even when it contains multiple localhosts. Starter can use every detected localhost inside its one selected project; Monthly or Lifetime is required when you save additional independent projects.

Share creates a public URL for a running local service. The service must be running before Decker can start the tunnel.

1. Click the Share button on a running browser service's row.
2. Choose a Share duration, from 30 minutes to 24 hours. The selection starts with your default from Settings and applies to this Share only.
3. Choose an open link or protect the preview with a password.
4. Copy the generated public URL after Decker verifies it.
5. Use Preview Check after someone opens the public URL.
6. Stop sharing when the preview should no longer be public.

The public address belongs to the saved Share binding. Stopping or expiring a Share disconnects that session, while the same address and Tunnel can be reused the next time you Share it.

Preview Check appears when Share is active. It helps you confirm that the public URL was opened, the app page loaded, and no important app requests failed.

The Requests view lists recent shared-preview requests with method, path, status, duration, and time.

Deploy uploads project files through Vercel's API. You do not need to create a Git repository before deploying.

1. Open Settings, then Integrations.
2. Connect your Vercel account and approve the connection.
3. Click the Deploy button on a supported service's row and confirm the deployment. To deploy again after a successful deployment, select Deploy again from the service menu.
4. Open the final production URL when the deployment is ready.

GitHub backup is separate from Vercel deploy. Decker copies the project root into a temporary Git repository and appends a snapshot to a project-specific backup branch without changing your local Git history.

1. Open Desktop Settings, then connect GitHub Repository Access.
2. Connect a backup repository from the project header.
3. Optionally include a backup snapshot when deploying.

Starter access works on one active device. Monthly or Lifetime work on up to three active devices owned by the same account.

You can review and remove active devices from the web dashboard if you need to use Decker somewhere else. A removed running device is signed out when it next refreshes and cannot register itself again in the background. Signing in again can reactivate that same device only when an active-device slot is available.

Open Settings from the desktop sidebar to manage account, appearance, startup behavior, preview preferences, integrations, and local system details.

• Account - signed-in account, providers, license, and session
• Appearance - Light, Dark, or System
• Behavior - startup and background behavior
• Preview - Simple Local URLs, fallback proxy port, and default Share Duration
• Integrations - Vercel deploy and GitHub repository access
• System - app version, OS compatibility, and updates

Decker requests the Vercel permissions needed for deploys.

• Deployments - create deployments and upload files
• Projects - create and configure Vercel projects

Your code stays on your computer while you run local services. Sharing and deploying only happen when you explicitly click Share, Deploy, or GitHub backup.

GitHub and Vercel OAuth use an expiring, one-time server handoff. After the Desktop consumes it, integration tokens are stored in your operating system's credential store instead of Decker's local config or project files.