Confirm the exact startup file, assigned port mechanism and bind address expected by the plan. Determine whether the panel uses a process integration that manages the listener differently.

1. Read the startup configuration supplied by the hosting panel or application service. Use its documented environment variable or integration rather than hardcoding a local development port.

2. Make the app validate and use the assigned listener value. Bind only to the interface required by the hosting architecture.

3. Configure the public domain through the panel or reverse proxy. Keep HTTPS termination and the internal application listener coordinated.

4. Start the app as the hosting account user through the supported process manager. Check the private startup log for the actual listener and any address-in-use error.

5. Test a public request and record how the service is restarted after deployment.

This minimal listener is for a deployment that explicitly supplies a numeric PORT and uses a same-server reverse proxy. Confirm the integration first; socket-based or panel-specific process integrations can require a different startup arrangement.

import http from 'node:http';

const port = Number(process.env.PORT);
if (!Number.isInteger(port) || port < 1 || port > 65535) {
  throw new Error('A valid platform-assigned PORT is required.');
}

http.createServer((request, response) => {
  response.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
  response.end('Example application is ready.\n');
}).listen(port, '127.0.0.1');

The loopback bind fits this specific local-proxy example. Use the interface prescribed by your provider when the proxy is elsewhere. Start the real application through the supported process manager and point the public hostname at its configured upstream.

Expected result: The HTTPS hostname reaches the expected application, while a missing or invalid assigned port causes a clear startup error instead of silently listening on a guessed development port.

Confirm the public HTTPS hostname reaches the expected application and that an unused direct public port has not been exposed unnecessarily. Verify the process returns after a controlled restart.

A 502 with a healthy-looking process can mean the proxy and app use different ports. An address-in-use error needs the conflicting process identified before any process is stopped.

• Deploying a Node.js application on an eligible Nabtech plan
• Running Express behind a trusted reverse proxy
• Investigating a Node app that works locally but fails on hosting
• Selecting a supported Node.js runtime for an existing app

• Node.js networking
• Express production practices

• Node.js HTTP server reference