Web Hosting

Last updated: August 2026

panel.javer.pro runs your app in a container — good for apps you're actively building and iterating on, where you want visibility into logs, environment variables, and resource usage. If you just want to point at a repo and have it work with zero configuration, Simple Hosting is the simpler option.

Deploying an app

There are three ways to get code onto Javer, all from the Deploy button on your dashboard:

• Connected GitHub repository — connect your account once, then pick a repo and branch. Pushing to GitHub does not redeploy your app. The code is pulled once, at the moment you press deploy. To ship a change, push it to GitHub and then deploy again.
• Public Git URL — paste any public GitHub or GitLab repository URL. No account connection needed.
• Direct upload — drop in a .zip of your project, a single .js file, or a single .html file.

Javer inspects what you sent and works out how to run it. A package.json means a Node.js app, and dependencies are installed for you. An index.html with no server means a static site. If your project is a zip containing one folder, that folder is unwrapped automatically.

Deploys with dependencies take time. A static site is ready in seconds; a Node app with a large package.json can take a minute or more while npm install runs. Keep the tab open until you see the URL.

Your app must listen on PORT

This is the single most common reason a deploy succeeds but the site shows an error. Javer assigns your app a port and passes it in as the PORT environment variable. Your app must read it rather than hardcoding a number.

In Node.js:

const port = process.env.PORT || 3000;
app.listen(port);

If you hardcode 3000 and ignore PORT, your app starts, appears healthy, and returns 502 Bad Gateway when visited — because nothing is listening where Javer is routing traffic. Static sites are unaffected; this applies to anything that runs a server.

Custom domains

Every app gets a free *.javer.pro subdomain the moment it deploys, with HTTPS already working — you do not need to configure SSL, request a certificate, or renew anything.

Your domain has to be on Cloudflare DNS. The address we give you only resolves inside Cloudflare. A domain sitting at GoDaddy, Namecheap, Route 53 or your registrar's default nameservers cannot be connected — move it to a free Cloudflare account first.

Then, on the app's detail page under Domains:

1. Add the domain. This only claims the name — no traffic moves yet.
2. Javer shows you a TXT record. Add it in Cloudflare.
3. Press Verify. Nothing is routed until this passes.
4. Add the CNAME record Javer shows you, and make sure the cloud icon beside it is orange (proxied), not grey.

HTTPS is issued for you once that is done. If your domain still shows nothing hours later, go back and check the TXT step — an unverified domain never starts working, however long you wait.

Environment variables

Open your app's detail page and use the Environment tab to add, edit, or remove variables. Names must be letters, numbers, and underscores.

Saving restarts your app straight away. Javer rebuilds the container with the new values and starts it again, so there is a short outage of a few seconds. Do not edit variables on a live app at a busy moment unless you mean to restart it. You do not need to press restart afterwards.

Deploy history & rollback

The last 5 successful deploys are kept. Anything older is deleted permanently and cannot be brought back. If a change breaks something, open the app's Deploy History tab and promote an earlier version in one click — no need to revert your code or redeploy from Git first. If you deploy six or seven times chasing a bug, this morning's known-good build is already gone, so keep your source in Git.

Rollback restores the application code. It does not roll back environment variables or database contents, so if a bad deploy also changed those, fix them separately.

Managed databases

Postgres and MySQL are available as managed resources, created from the Databases tab. Javer generates the password for you and shows the full connection details once, at creation time. Copy them then — they are stored encrypted and cannot be displayed again. If you lose them, create a new database.

A database counts against the same account allowance as your apps and VMs, so a 1 GB database uses 1 GB of your plan's memory budget.

Current limitation: managed databases are reachable from your other Javer apps, but not from the public internet. You cannot yet connect to one directly from your laptop with psql, TablePlus, or pgAdmin. If you need external access today, run your database inside one of your own apps instead.

VMs

When an app is the wrong shape — you need a full Linux machine, a custom runtime, system packages, or a long-running background process — create a VM from the VMs tab.

VMs come with a browser-based terminal, can be resized after creation, and support snapshots. Resizing requires the VM to be shut down first; snapshots can be taken while it runs.

Current limitation: the browser terminal is the only way in. VMs run on an internal network with no route from the public internet, so you cannot yet SSH to one from your own machine — an SSH key you generate has nowhere to connect. Everything you would do over SSH, you do in the browser terminal instead.

A GPU add-on is available for workloads that need one, subject to availability — there is a single GPU in the pool, so if another customer holds it, GPU requests are declined until it frees up.

Network

Your account has its own private network with a dedicated subnet. VMs placed on it can talk to each other privately, and stay separated from every other customer's machines.

Under Network you can add firewall rules. Each has a direction, a priority (the lower number wins), allow or deny, a protocol and ports, and the address ranges it covers.

Rules are aimed at machines using tags. You label a machine with a tag, and the rule applies to every machine carrying that tag, including ones you create later. A rule whose tag matches nothing applies to nothing — the panel will tell you when that happens.

Two rules are always in force at the lowest priority and cannot be removed: deny everything inbound, and allow everything outbound. Your rules are what you carve out of that.

The Activity view is traffic volume only. Its "dropped" number is network-card statistics, not blocked connections, and it will normally read zero even when your firewall is working perfectly. Do not use it to judge whether a rule is working.

This applies to VMs. Apps are not configured from this tab.

Team accounts

A team lets several people manage the same apps, VMs, and databases under one bill. Create one from Settings → Teams and invite members by email address.

An invited person does not need a Javer account yet — the invite resolves automatically the first time they sign in with that email. Invites are free; you are billed per seat, meaning per member who has actually joined.

A team has its own resource pool sized by seat count, separate from each member's personal account. Personal apps stay private and are never visible to your team.

API keys

Create an API key under Settings → API Keys to use Javer's REST API from scripts or CI. The key is shown once when created — copy it immediately, as only a hash is stored.

Send it as a bearer token on any API request:

curl -H "Authorization: Bearer jvr_live_..." \
     https://panel.javer.pro/api/apps

Keys do not expire. Revoking one takes effect immediately. To rotate, create the replacement first, switch your scripts over, then revoke the old key.

Plan limits

Every plan includes every feature above — paying more buys capacity, not unlocked functionality.

"Items" counts apps, VMs, and databases together. Memory and storage are a shared pool — a Pro account can run one 3 GB app or three 1 GB ones. Downgrading never deletes anything: existing resources keep running, but you cannot create new ones until you are back within the smaller plan's budget.

Troubleshooting

My site shows 502 Bad Gateway. Your app almost certainly is not listening on PORT. See the section above.

The deploy said it failed, but the app exists in my dashboard. Long builds can time out in the browser while finishing successfully on our side. Check your dashboard before retrying — if the app is there, it deployed.

"You already have an app with that name." That name is taken by an existing app, including one from a deploy you thought had failed. Delete it or choose a different name.

I hit my plan limit. Delete something you are not using, or upgrade under Settings → Billing. Limits apply to your total across apps, VMs, and databases.

Still stuck? The quickest route is the Support tab in your panel — the assistant there can already see your plan and your apps, so you do not have to explain your setup. If it cannot solve something it opens a ticket with a case number and a human replies on that ticket. Not logged in? Use javer.pro/support, and if you are locked out of your account entirely you can pull up an existing ticket there with your case number and the email you used. You can still email support@javer.pro if you prefer with your app name and roughly when the problem started.