Hostinger runs shared hosting and VPS plans out of Lithuania, and its newer Express.js hosting promises a managed Node.js runtime without server administration. Rather than take that at face value, I built a minimal Express app engineered to reveal exactly how the platform handles ports, environment variables, and Node versions, three things a landing page can describe but only a live deployment can prove.

Hostinger Express.js VPS Hosting

Hostinger’s Express.js hosting provides VPS resources, full root access, and an optimized environment for deploying fast and scalable Node.js applications.

Hostinger を訪問する

Pros and Cons

Rating Breakdown

To score Hostinger’s Express.js hosting, I applied HostAdvice’s rating methodology, the same standardized system used across every review on this site, so the numbers below reflect real testing rather than the claims on Hostinger’s own landing page.

Deploy Express.js with Hostinger

Hostinger makes Express.js deployment simple with flexible VPS resources, full server control, and support for Node.js applications and APIs.

Hostinger を訪問する

Plans and Pricing

Hostinger sells Express.js hosting as two tiers under its Web Apps hosting line, Business and Cloud Startup, both built for Node.js-based deployment rather than a general VPS.

Business covers a smaller allocation of Web App slots and moderate resources, while Cloud Startup roughly doubles CPU and RAM, adds a dedicated IP, and includes priority 24/7 support along with a traffic power boost for busy periods.

Billing runs across 1, 12, 24, and 48-month terms, with the deepest discount attached to the 48-month option.

Money-back guarantee: This falls under Hostinger’s standard hosting refund terms, a straight 30-day window from the date of purchase with no cooldown between claims, rather than the tighter VPS-specific policy.

Free trial: I found no dedicated free trial for Express.js hosting, only the 30-day money-back guarantee.

Payment methods: Card (Visa, Mastercard, Amex, Discover), PayPal, Google Pay, AliPay+ China and Hong Kong, and Coingate for crypto. Crypto payments fall outside the refund policy entirely.

What’s bundled in: Every tier includes a free domain, free business email, and managed SSL certificates for the first year, plus GitHub integration at no extra cost. The global CDN is listed as included on every plan, but my own deployment shipped with it switched off by default, so treat it as something to enable yourself rather than something already working the moment your app goes live.

Features

• GitHub integration with automatic deployments
• IDE-based deployment via Hostinger Connector
• Global in-house CDN, manual activation needed
• Managed SSL certificates on every site
• Malware protection enabled by default
• Daily automatic backups included standard
• Environment variable manager with .env import
• Web application firewall included free
• Unlimited bandwidth on every plan

Hostinger VPS for Express.js

Run Express.js applications on Hostinger VPS with dedicated resources, root access, and the flexibility to configure your server for custom Node.js projects.

Hostinger を訪問する

Performance

This is the first deployment in my testing where the built-in speed tool actually had history to show me rather than a single fresh snapshot.

The Past Results table on this dashboard already held two prior runs by the time I looked at it, so instead of opening with a single score, I want to start with what that history actually shows.

1. What the Trend Line Shows

Desktop moved from 99 to a perfect 100 between two runs roughly an hour apart, with nothing about the deployment changed in between.

That’s normal variance for a Lighthouse-style tool rather than a real improvement I made happen, and it’s useful to see it laid out in a table rather than inferred from two separate dashboard visits. It confirms what I’ve suspected in isolated snapshots elsewhere: treat any single score as a point in a range, not a fixed number.

2. Desktop and Mobile Results

Both device tests landed at a perfect 100, and the gap between them is small enough to lay out side by side:

This is the strongest combined result of anything I’ve measured on this host, and it deserves a real explanation rather than just a number.

This deployment is a persistent Node process, rendering a response on every request rather than serving pre-built static files. I expected that to cost something in raw speed compared to a static deployment.

It didn’t, at least not here. The likely reason is that my test app is deliberately tiny, one route, one HTML page, minimal CSS, nothing heavy to compute per request, so the rendering model mattered far less than the size and simplicity of what’s actually being served.

A larger, database-backed Express app doing real work on every request would be a different test entirely, and I want to be clear that this result reflects a lightweight app, not a blanket claim that a live Node process matches static hosting for speed in every case.

3. Reading the Diagnostics

Both scans included a diagnostics breakdown, and several items, document request latency, avoiding redirects, and the network dependency tree, scored 0 on both desktop and mobile. Read on its own, a 0 looks like a failure. It isn’t.

These are opportunity audits measuring potential savings, and a 0 means the tool found nothing left to trim, the best outcome available, not a problem to fix.

Two diagnostics landed in genuinely middling territory instead:

• Use efficient cache lifetimes: scored 50 on both desktop and mobile
• Render-blocking requests: scored 50 on desktop, 0 (no issue found) on mobile

Cache lifetimes sitting at 50 is the one real, actionable item here. Setting longer cache headers on static assets like the CSS file this app serves is a small, specific change that could push this from a very good score to a technically flawless one.

Every optimization link under the diagnostics panel on both scans pointed to WordPress-specific content, a WordPress speed guide, an image optimization article, a video walkthrough. None of it applies to an Express deployment. The speed test itself measured this Web App correctly. The advice attached to it hasn’t been built for anything outside the WordPress hosting product.

Overall Verdict on Performance

This is the best result I’ve measured on Hostinger’s Web Apps hosting, a genuine 100 on both desktop and mobile, backed by a real trend line rather than a single lucky snapshot.

What makes this result stand out is that it came from a persistent Node process handling every request live, not a static build with an inherent speed advantage, which says more about how lightly a small, well-built Express app can run here than it does about raw infrastructure alone. The diagnostics hold up once you read the 0 scores as passes, and the one genuine 50, cache lifetimes, is a specific, fixable detail rather than a real weakness.

The recurring gap is the help content bolted onto the tool, which still assumes every visitor is running WordPress. It doesn’t touch the accuracy of the score, but it means you won’t find anything useful there if you click through looking for Node-specific advice.

Express.js Hosting Plans with Hostinger

Hostinger’s Express.js VPS plans offer scalable resources, complete server control, and a reliable environment for APIs, web apps, and backend services.

Hostinger を訪問する

Ease of Use

I tested Hostinger’s Express.js hosting from a blank signup form through to a live, persistent Node process running in the browser. Before touching the signup page, I made a decision that shaped the rest of this test. Rather than deploying a typical demo project, I built a deliberately bare-bones Express app myself, a single server file with three routes, styling pulled from a separate CSS file, no database, no authentication, no build tooling.

If anything broke once this app went live, I wanted the failure to point at the hosting environment, not at some complexity I’d introduced in the code.

That decision paid off. The app surfaced two real, specific findings once it went live, not just a wall of green checkmarks.

1. Registration

I started on the Express.js hosting landing page. Clicking “Claim deal” didn’t drop me into checkout the way I expected. It scrolled the page down to a pricing table instead, putting Business and Cloud Startup side by side so I could compare before committing to anything.

I picked Cloud Startup, since it carries 10 Web App slots against 5 on Business, plus a dedicated IP and priority support, more headroom than I needed for one test app, but the plan I wanted to review.

That took me into the cart, where everything sat on one screen:

• Plan: Startup plan (Cloud Startup), with 1, 12, 24, and 48-month terms and a “Best value” tag on 48 months
• Bundled extras: a free domain and free mailboxes, both already reduced to $0 in the order summary
• Domain search: built directly into the cart rather than pushed to a later step

I selected 48 months for the lowest published rate, then moved into registration. This time I built a genuinely new account rather than reusing one already signed in, so I could see the actual signup experience a first-time visitor gets.

The registration form offered three paths in: Google, GitHub, or email and password. I went with email, filled in a password, left the optional phone number field blank, and skipped the marketing consent checkbox since it came unticked by default.

After clicking Register, I landed on billing address and payment, both on one page with no separate redirect. Card, PayPal, Google Pay, AliPay+ China and Hong Kong, and Coingate were all listed as options.

I paid by card. The charge went through immediately, not on a delay, and a confirmation email landed within seconds.

How I found registration: Clean and fast, with nothing hidden. Pricing sat in full view before I ever created an account, the free domain and mailboxes applied automatically rather than requiring an extra click, and the card charge was real and immediate rather than a placeholder step before some later confirmation.

2. Dashboard and Client Area

Once payment cleared, I landed in hPanel, Hostinger’s own account panel that replaces a third-party interface like cPanel.

It greeted me by name and led with an AI prompt bar, a text field for typing a request in plain language, alongside shortcuts for Get domain, Create website, Get email, Migrate site, Get VPS, and Try email marketing.

Next, I looked at the left sidebar, since that’s where the real account structure lives: Home, Websites, Domains, Emails, and More services at the core, then grouped sections underneath for Hostinger apps, AI agents, and Dev tools including VPS and GPU.

Websites is where a deployment like mine would actually live, so I already knew where I was headed.

What I thought about the dashboard: hPanel does the job of a genuine account hub, and Websites stayed one click away in the sidebar the whole time, regardless of how much else was happening on the home screen. The unprompted feedback widgets are a rough edge that Hostinger should fix, since they undercut the polish of an otherwise clean, functional interface.

3. Deploying Your App

I clicked into Websites next. My Cloud Startup plan was already listed there, empty, with an Add website button sitting next to it.

Clicking that opened four paths: AI Builder, WordPress, Custom PHP/HTML website, and Deploy Web App. I picked Deploy Web App, since that’s the option built for exactly what I was about to do.

The next screen asked for a domain or subdomain. I used the temporary domain option, since I wanted this test focused on the deployment mechanics themselves rather than domain setup.

After that came the import step, with three real paths: Import Git repository marked Recommended, Upload your files as the alternative, and a third option for deploying straight from a code editor through the Hostinger Connector.

I chose GitHub. Since my account was already connected from earlier testing, the repository list loaded immediately rather than sending me through an authorization screen.

I scrolled down to hostinger-express-demo and clicked Deploy.

That opened a build review screen rather than kicking off the deployment blind. The framework preset came back correctly as Express, and everything else sat there editable:

That Node version stopped me before I moved forward. Node 18 reached end of life in April 2025, which means the default runtime this deployment offered me no longer receives security updates from the Node.js project itself

I want to flag that plainly rather than gloss over it, since it’s not a Hostinger-specific bug, but it is something you’d want to check and change before accepting the default rather than discovering it later.

Next, I decided to test the environment variable flow rather than skip past it, since that’s a detail a lot of reviews leave untested. Clicking Add next to Environment variables opened a proper modal, not a single text box: a Key field, a Value field, an “Add more” button for additional variables, and an “Import .env” shortcut for pulling several in at once from a file.

I typed APP_NAME as the key and Hostinger Express Demo as the value, clicked Finish, and watched the build review screen update to show “Added: 1” next to Environment variables. That confirmed the value actually registered before I moved on, rather than leaving me to find out during the build.

With the settings confirmed, I clicked Deploy. A live progress screen opened with real build logs underneath, npm installing 69 packages, flagging 0 vulnerabilities, all visible as it actually happened rather than hidden behind a spinner.

The build finished in under a minute, and the completed screen labeled this deployment plainly as a persistent Node process, correctly distinguishing it from a static build the way an Express server actually behaves.

Then I opened the live URL myself, since a completed-deployment screen isn’t proof anything actually works. This is where the app I’d built earlier did exactly what I designed it to do:

That amber port binding result is the single most important finding from this entire deployment, so I didn’t stop at the page’s own summary. I went and checked the app’s /api/status JSON endpoint directly to confirm it a second, independent way.

It reported portSource: “fallback default” in plain text, not something I had to infer from a color on a page. Hostinger never injected a PORT environment variable into this deployment. The app only worked because I’d built it with a hardcoded fallback.

If an Express app you deploy here expects to read process.env.PORT with no fallback of its own, that mismatch could mean it never receives traffic correctly, and nothing earlier in the deployment flow gives you any warning that this is a possibility.

How I found the deployment process: Fast where it counts, and honest about what it actually deployed, correctly labeling a persistent process rather than borrowing static-build language that wouldn’t apply. The environment variable modal, with real key-value pairs and .env import, is more capable than I expected going in. But two things here carry real weight. The default Node version is already outside its support window, and the platform’s silent fallback on port binding is exactly the kind of gap that only surfaces once you deploy something built to expose it, not from anything on the pricing page.

4. Hosting Management

After the build finished, I clicked into the deployed site to see where ongoing control over it actually lives.

That opened a dedicated dashboard, separate from the general hPanel home screen, with a left-hand menu covering Dashboard, Deployments, Environment variables, Runtime logs, Hosting Plan, Performance, Analytics, Security, Domains, Files, Databases, and Advanced.

At the top sat the site name, a Connected with GitHub badge, and a Redeploy button. Below that, four status pills, and this is where I found a second real issue. Running, Auto-deployment, and Malware protected all showed green. CDN did not. It sat there gray and disabled, the only one of the four not switched on by default.

I scrolled further down to confirm I wasn’t misreading it, and found a “Tips to improve” card that settled the question. It prompted me directly to enable the CDN, citing a claim of roughly 40 percent faster load times, with an Enable CDN button sitting right there. That’s the dashboard confirming its own gap rather than me guessing at it.

Next, I checked the Last deployment card, which confirmed Express as the detected build tool and Node 18.x again, alongside repository, author, branch, commit message, and a build time of 15 seconds. Then I looked at the Essentials card, database connection, backups, file manager, runtime logs, and cache controls grouped together.

The Backups entry showed a malformed date, “2020 09 18 11:20,” an invalid format that doesn’t match when this site was actually deployed. I want to flag this directly rather than read past it, since this is the same kind of display bug I noticed elsewhere on this dashboard, and it deserves being taken seriously on its own.

Finally, I checked the Performance card and the resource usage panel. Desktop scored 99, with mobile not yet scanned. Resource usage confirmed how lightly this deployment sits on the plan: 0.05 GB of 100 GB disk used, 3 MB of memory, and 2 of 10 available Web App slots claimed.

What I thought about hosting management: The structure here covers what a Web App deployment actually needs, environment variables and database connections both live in the sidebar rather than requiring a separate control panel or a terminal session. CDN sitting off by default is a real, actionable finding, not a footnote, since it directly affects the load-time numbers this same dashboard reports in other places. The malformed backup date is a repeat of the same display bug, and repetition is what turns a small glitch into something that erodes trust in the rest of the panel’s numbers.

Overall Verdict on Ease of Use

Deployment here moves fast and gets the fundamentals right. The build tool was correctly identified as Express, the environment variable flow is genuinely capable with a real modal and .env import, and the completed build was labeled honestly as a persistent Node process rather than reusing language that doesn’t apply.

Two findings deserve real weight before calling this simple. The default Node version, 18.x, is already past its end-of-life support window, and Hostinger’s platform does not inject a PORT environment variable by default, confirmed two separate ways, through the live app’s own self-check and through its JSON status endpoint, which means an Express app expecting one could silently fail to receive traffic.

CDN sitting disabled by default, confirmed by the dashboard’s own upsell card, is a smaller but real gap in what actually ships active out of the box. None of this makes the platform unusable. It means you should check the Node version dropdown, confirm your app’s port-handling logic works with a fallback, and switch on CDN yourself rather than assuming every production-ready setting is already in place.

Build Express.js Apps on Hostinger

Hostinger provides a flexible VPS environment for Express.js with scalable resources, root access, and easy deployment of Node.js web applications.

Hostinger を訪問する

Level of Support

Hostinger backs this plan with three ways to get help: Kodee, an AI agent built into the dashboard, a knowledge base of self-service articles, and human support as a fallback once Kodee can’t close something out.

• Kodee (AI Agent): built to turn a plain-language question into a direct answer, or a direct action, across your hosting account rather than pointing you at a generic article.
• Human support: available as an escalation path, though rarely needed since Kodee resolves most queries on its own.
• Knowledge base: the self-service article library, searchable and organized into category tiles by product and topic.

I tested Kodee with a question built directly around what my own deployment had already shown me, then searched the knowledge base to see how well Express and Node.js content actually surfaces.

1. AI Support (Kodee)

Kodee sits behind the Agent button at the top right of every hPanel screen. Opening it splits into two modes rather than one general chat, an “Agent” mode for premium tasks like file creation and scheduled jobs, and a “Support” mode narrowed to quick help with your account, hosting, and websites. I used the general Agent chat, since that’s the entry point most people land on first.

I asked Kodee about the exact question my own deployment had already answered for me:

“My Express app is deployed on Hostinger’s Node.js hosting. Does the platform automatically inject a PORT environment variable that my app needs to listen on, or does it expect the app to use a fixed port? My server currently falls back to port 3000 if PORT isn’t set, and it’s running, but I want to know if that’s relying on a coincidence rather than the actual setup. Also, my deployment defaulted to Node 18.x. Since that version is past its official end-of-life, can I change it to a newer version after deploying, and does that require a redeploy or just a setting change?”

Kodee opened by stating it was checking the active site’s deployment details before answering. Then it gave a direct, confident answer to the port question:

“Yes, Hostinger’s managed Node.js hosting provides a PORT value, and your Express app should listen on it rather than depend on a fixed port such as 3000.”

It backed that with a recommended code pattern, const port = process.env.PORT || 3000, and cited Hostinger’s own Express.js documentation page directly.

I need to be direct about what this means. That answer is wrong for the deployment it was supposedly checking. My live app’s own self-check had already reported its port binding status as amber, with the plain-text explanation that no PORT environment variable was set and the app fell back to its hardcoded default.

I confirmed that a second, independent way through the app’s /api/status JSON endpoint, which returned portSource: “fallback default” in plain text.

That field does not leave room for interpretation. No PORT variable reached my app. Kodee’s claim that Hostinger provides one directly contradicts hard evidence from the exact deployment it said it was checking.

To Kodee’s partial credit, it did hedge slightly in the same answer, adding that if the fallback currently works, Hostinger “may be routing the deployment through the configured application port,” and called relying on 3000 “not the portable or recommended setup” regardless.

That’s a softer, more defensible position than the opening line, but it still starts from a factual claim about platform behavior that my own test data doesn’t support.

On the second half of my question, Kodee’s answer was more straightforward and I have no evidence contradicting it:

That guidance is specific and actionable, and I didn’t test it myself, so I’m reporting it as Kodee’s answer rather than something I independently verified.

What I thought about Kodee: The Node version guidance was clear and useful. The port answer was not. Stating plainly that Hostinger injects a PORT variable, backed by a citation, when my own deployment’s JSON endpoint says otherwise in explicit terms, is a real accuracy problem, not a matter of interpretation. A developer who asked this exact question and trusted the answer at face value could remove their fallback logic entirely, based on advice that contradicts what their own app would tell them if they checked.

2. Knowledge Base

The knowledge base overview page organizes into category tiles by product: Getting Started, hPanel, Hostinger AI Builder, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel, and About Hostinger.

There’s no tile built for Web Apps hosting on its own, so browsing by category alone wouldn’t surface Express-specific content.

I searched “express js” directly. It returned 8 results, and unlike a broader single-word search, every result here was genuinely relevant to Node.js development:

• Connecting a Hostinger MySQL database to a Node.js application
• How to add a Node.js Web App in Hostinger
• Which databases and data tools are supported at Hostinger
• How to deploy apps built with Codex on Hostinger
• Docker Catalog applications
• How to use the MEVN Stack VPS template at Hostinger
• How to use the MEAN Stack VPS template at Hostinger
• How to find the website’s configuration file at Hostinger

I opened the top result, “Connecting a Hostinger MySQL database to a Node.js application,” to check the actual content.

It’s a genuinely thorough article: it walks through creating a MySQL database in hPanel, configuring environment variables two different ways, and draws a clear line between server-side Node.js apps like Express and Next.js, which support a restart from the dashboard, and static sites, which don’t run a persistent process and don’t have that option at all.

It includes a working mysql2 connection example that reads credentials from environment variables, SQL for creating the required tables, and a troubleshooting section covering access-denied errors, connection failures, and environment variables not loading correctly.

What I thought about the knowledge base: This held up better than a single-category page would suggest. Search returned a tight, relevant set of results rather than noise, and the article I opened was specific, code-backed, and correctly distinguished between deployment types rather than treating every Web App the same way. This is the strongest self-service content I’ve come across while testing this product.

Overall Verdict on Support

Support here is genuinely split between its two channels, and they don’t deserve the same grade. The knowledge base performed well: search returned relevant results for “express js” without noise, and the article I opened was thorough, code-backed, and accurate about how server-side Node.js apps actually behave. Kodee is where the real problem sits.

It gave clear, actionable guidance on changing the Node version, but its answer to the port question was confidently wrong, stating that Hostinger injects a PORT variable when my own deployment’s JSON status endpoint directly says it didn’t.

That’s not a minor imprecision. It’s a factual claim about live infrastructure behavior that contradicts hard evidence from the exact site Kodee said it was checking, delivered with a documentation citation that made it sound more authoritative than it was.

Use Kodee for account and configuration questions where you can verify the answer yourself, and don’t take a claim about your specific deployment’s behavior at face value without checking it the way I did here.

Hostinger Express.js Hosting

Deploy Express.js projects on Hostinger VPS with flexible server resources, full root access, and an environment suited for scalable Node.js applications.

Hostinger を訪問する

Do We Recommend Hostinger Express.js Hosting?

Yes, with a real caveat about how much you should verify yourself. Deployment worked well: GitHub import was immediate, Express was correctly identified without guessing, and the completed build was labeled honestly as a persistent Node process. Performance backed that up with a genuine 100 on both desktop and mobile, the strongest result across everything I tested on this host.

The caveat sits with support. Kodee answered a direct technical question about PORT environment variable injection with a confident, citation-backed claim that contradicted hard evidence from my own live deployment. That’s not a small mistake, it’s the kind of answer a developer could act on and break their app over. Add in a default Node version already past its end-of-life window and a CDN toggle that ships off despite being listed as included, and the pattern is clear: the infrastructure performs, but you need to verify what it tells you rather than take it at face value.

This is a solid pick for a developer comfortable deploying fast and then checking the specifics, port handling, Node version, CDN status, against their own app rather than Hostinger’s own claims about them. If you’d rather trust every automated answer without a second look, budget time to confirm these details yourself first.

Hostinger

5.0

2,471 user reviews

￥250 /mo

最低価格

Hostinger を訪問する

Rating based on expert review

• 使いやすさ
  4.9
• サポート
  4.9
• 機能
  4.8
• 信頼性
  4.7
• 価格
  4.5