Web Hosting

Last updated: July 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. Pushes to that branch redeploy automatically.
• 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 container 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.

To use a domain you own: open the app's detail page, add the domain under Domains, then point your domain's DNS at the address shown there. SSL is issued automatically once DNS resolves. DNS changes can take up to a few hours to propagate, so a newly added domain may 404 briefly before it starts working.

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.

Changes are not live immediately. A running container keeps the environment it started with, so your app picks up new values on its next restart or redeploy. Use the restart button after editing if you want them applied straight away.

Deploy history & rollback

Every successful deploy is kept. If a change breaks something, open the app's History tab and roll back to any previous version in one click — no need to revert your code or redeploy from Git first.

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 an app container instead.

VMs

When a container 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 (no SSH client needed), can be resized after creation, and support snapshots. Resizing requires the VM to be shut down first; snapshots can be taken while it runs.

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.

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/containers

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? Email ask the support assistant or email [email protected] with your app name and roughly when the problem started.