Linux Hosting

What is Linux hosting and who is it for?

Linux hosting is a shared hosting service in which a website runs on a Linux-based server with open-source components such as PHP and MySQL. The vast majority of PHP sites on the internet run in this environment, and the documentation of popular software from WordPress to Laravel assumes a Linux server.

Unlike general web hosting plans, LIONFIN Linux hosting puts the developer workflow at the centre. Instead of uploading your code file by file over FTP, you can connect over SSH and pull from a Git repository, install dependencies from the command line and define scheduled tasks with cron.

These plans are most useful for:

• PHP developers building projects with Laravel, Symfony, CodeIgniter or Slim,
• agencies keeping client sites under version control with Git,
• small product teams that want to run staging and production on separate domains,
• developers who are comfortable in a terminal but do not want to deal with server updates, firewalls and backup infrastructure.

Which developer tools come with Linux hosting?

PHP version selection, SSH access, Git deployment and cron job management are standard on every Linux hosting plan. They come alongside NVMe storage, MySQL databases, email on your domain and unmetered traffic.

On the resource side, every plan has a defined number of CPU cores and memory allocation. Short, heavy jobs such as Composer installs, image processing or bulk data imports draw from this share, so it is a good habit to run builds and imports outside peak visitor hours.

How do you choose a PHP version, and why does it matter?

Choose the newest PHP version that your application and its libraries support. Current versions receive security patches and usually run the same code faster; staying on an end-of-life version means using software whose holes are no longer fixed.

Follow this order when choosing:

1. Check the application’s requirements: the documentation for your Laravel, Symfony or WordPress version lists the supported PHP range. In Composer projects the "php" line in composer.json shows this constraint.
2. Try it on staging first: change the version on a copy under a subdomain and watch the error log.
3. Check extensions: make sure extensions such as intl, gd, zip and pdo_mysql are enabled on the version you choose.
4. Adjust memory and upload limits: for large uploads or heavy reports, raise memory_limit and upload_max_filesize within the plan’s limits.

Use php -v to confirm that the PHP on the command line is the same version that serves web requests; a different version kicking in for cron and Composer commands is the most common surprise. Read the migration notes for breaking changes before moving between major versions.

How do you deploy with SSH and Git?

Deployment on Linux hosting means connecting to the server over SSH, pulling the latest version from the Git repository in the project folder and installing dependencies. This removes the missing files and version mix-ups you get when copying files over FTP.

We recommend using an SSH key rather than a password to connect. The server name, username and SSH port are listed in your service details.

A typical Laravel deployment consists of these commands:

ssh -p SSH_PORT user@server-name
cd ~/project
git pull origin main
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache

If Composer is not available on the server, download composer.phar into your project folder and run it as php composer.phar install. For private repositories, the safest approach is to add the public part of the SSH key on the server to your GitHub or GitLab account as a read-only “deploy key”.

During deployment it is important that the .git folder is not exposed in the web root: keep the project root one level above the web root and publish only the public folder.

How do you publish Laravel and custom PHP projects?

The rule for publishing Laravel and similar framework projects on Linux hosting is to point the domain’s document root to the project’s public folder. That way your .env, vendor folder and source code stay inaccessible from the browser.

• Document root: set the domain’s root directory in the panel to project/public. If that is not possible, a rewrite rule in the project root can forward requests to the public folder via an .htaccess file.
• Environment file: set APP_ENV=production and APP_DEBUG=false in .env; the database name, user and password must match the values you created in the panel.
• Write permissions: the storage and bootstrap/cache folders must be writable by the web server; 644 for files and 755 for folders is enough in most cases. Never use 777.
• Queues: a permanently running queue:work process is not suitable for a shared environment; you can process queues with cron at short intervals using the --stop-when-empty option.

Once a project needs background workers, extra PHP extensions or services like Redis, it has outgrown shared hosting and a virtual server is the next step.

Do Python and Node.js applications run on Linux hosting?

Yes, alongside PHP, Linux hosting plans also support Python and Node.js projects; but because of the nature of a shared environment, these should be thought of as lightweight web applications started on demand. These plans are not the right place for background processes that must stay up permanently.

Suitable scenarios:

• a small web panel, API or form handler written with Flask or Django,
• a low-traffic API or server-rendered pages written with Express,
• publishing the output of static site generators (for example Next.js static export, Astro, Hugo).

Unsuitable scenarios are WebSocket servers, Discord or Telegram bots, permanently running queue workers, machine learning models and real-time applications that hold persistent connections. These need an environment with resources dedicated to you.

You can confirm which Node.js and Python versions are enabled with a support ticket before ordering. For a detailed roadmap see the Node.js hosting and Python hosting pages; on a virtual server, apps are typically run with PM2 behind Nginx.

How do you set up scheduled tasks with cron?

Cron is the Linux scheduler that runs a given command automatically on the minute, hour, day and month pattern you define. On Linux hosting you can define cron jobs from the panel or over SSH with the crontab -e command.

A cron line consists of five time fields and a command. The typical line for triggering the Laravel scheduler every minute is:

* * * * * cd /home/USER/project && php artisan schedule:run >> /dev/null 2>&1

For a nightly database dump, a line like this can be used:

30 3 * * * mysqldump --defaults-extra-file=$HOME/.my.cnf DATABASE | gzip > $HOME/backup/db-$(date +\%F).sql.gz

Things to watch out for:

• PATH may be restricted in the cron environment; if necessary, write the full path to the PHP binary and check which version runs with php -v.
• % signs have a special meaning in cron and must be escaped with a backslash.
• Heavy jobs that run too often eat into your CPU share; choose the interval you really need.

How do you separate staging and production on Linux hosting?

A staging environment is an exact copy of your live site running on a separate subdomain (for example test.yourdomain.com) with a separate database. You try updates, a new PHP version or database changes there first, and your visitors never see the error.

A simple but solid setup on Linux hosting looks like this:

1. Create a subdomain: create the test subdomain in the panel and point its document root to a separate folder.
2. Create a separate database: import a dump of the live database into it; staging must never connect to the live database.
3. Map Git branches: the staging folder tracks the develop branch and the live folder tracks main.
4. Separate environment files: each environment has its own .env, its own keys and its own email settings; stop staging from emailing real customers.
5. Hide it from search engines: password-protect the staging area or add a noindex header, otherwise it can be indexed as duplicate content.

This setup needs at least two sites and two databases; the Economy plan includes one site, so if you will use staging it makes sense to start with a higher plan. Site and database counts per plan are shown in the table on this page.

Linux hosting or Windows hosting?

If your project uses PHP, MySQL, Python or Node.js, choose Linux hosting; if it uses ASP.NET, ASP.NET Core or MSSQL, choose Windows hosting. What decides it is the technology your application runs on, not the operating system on your own computer.

For the Windows side, see the Windows hosting plans. If your panel habits are what matters, you can also use the same Linux infrastructure with cPanel hosting or Plesk hosting plans.

How do you choose between Linux hosting plans?

When choosing a Linux hosting plan, take into account the number of projects, the number of databases each project needs and the CPU share required during deployments or builds. Disk space is usually enough for source code and the vendor folder; user uploads and log files, however, grow over time.

• Economy Linux Hosting: one live project; a personal application or a single client site.
• Popular Linux Hosting: a live site with a separate staging copy, or a few small projects, each with its own database.
• Professional Linux Hosting: an agency workflow, several client projects, more CPU and memory headroom and smoother Composer runs and imports.

Log and cache files quickly increase the file count; you can approach the file count (inode) limit even if your disk is not full, so clean up old logs and caches regularly. Monitor your resource usage in the panel and move up a plan when you need to; current plan values are shown in the table on this page.

How are security and backups handled on Linux hosting?

On Linux hosting, LIONFIN manages server, network and operating system security; the security of your application code, secret keys and access methods is your responsibility. On the infrastructure side, the RouteFence firewall performs network-level DDoS filtering, and servers are monitored by 24/7 NOC and SOC teams.

A checklist for the developer side:

• Use keys rather than passwords for SSH logins and delete keys you no longer use.
• Keep .env, .git and configuration files outside the web root.
• Turn off debug mode in production; error details can expose database credentials.
• Update dependencies regularly and check for known vulnerabilities with composer audit.
• Redirect all traffic to HTTPS with the free SSL certificate.

As for backups, your code already lives in a Git repository; what really needs protecting is the database and user uploads. You can see your plan’s backup coverage on the plan card; in addition, taking a nightly database dump with cron and copying it to another location creates a solid setup in line with the 3-2-1 backup rule.

When should you move from Linux hosting to a VPS?

Move from Linux hosting to a virtual server when you need to install software that requires root access, manage a permanently running process, or have resources fully dedicated to you. None of these three needs can be met in a shared environment.

• System software: if you need Redis, Elasticsearch, RabbitMQ, custom PHP extensions or a different database engine, choose a VPS server with full root access.
• Containers: if you package your application with Docker, see the configuration advice on the Docker hosting page.
• Consistent performance: for heavy database work and projects that cannot tolerate neighbour effects, a VDS server with fully dedicated cores is a better fit.
• Growing without taking on administration: if you do not want to manage a server but need more dedicated resources, business hosting is the intermediate step.