Guides

• 1: Catch-all VirtualHost with 301 redirect on Apache
• 2: Change public IP without downtime
• 3: Copy a SQL database
• 4: Copy files between environments
• 5: Enable IPv6
• 6: Enable X11-Forwarding on VPS
• 7: FAQ
• 8: Force HTTPS on Apache behind Nginx load balancer
• 9: Force HTTPS with Tomcat
• 10: Log real client IP behind a proxy
• 11: Migrate an environment to another provider
• 12: Nginx LB HTTP to HTTPS redirect
• 13: Nginx redirect to HTTPS
• 14: Node.JS NPM Module Problems
• 15: PHP max upload file size
• 16: Redirect nginx
• 17: Restrict phpMyAdmin access
• 18: SMTP on port 25 not working

1 - Catch-all VirtualHost with 301 redirect on Apache

Overview

If you want to make sure all traffic only uses your preferred domain name you can create a catch-all VirtualHost in Apache and redirect to the VirtualHost with the preferred domain name.

Configuration

On your apache node select config and edit the httpd.conf file. Replace the current <VirtualHost ...> section with the following and replace mydomain.com with your domain name.

Note: Before you make any changes, it is always recommended to create a backup copy of the old configuration file.

<VirtualHost *:80>
 DocumentRoot /var/www/webroot/ROOT
 ServerName mydomain.com
 ErrorLog logs/mydomain-error_log
 CustomLog logs/mydomain-access_log common
</VirtualHost>
<VirtualHost *:80>
 ServerName www.mydomain.com
 ServerAlias *
 Redirect 301 / http://mydomain.com/
 ErrorLog logs/redirect-error_log
 CustomLog logs/redirect-access_log common
</VirtualHost>

In this example all traffic that is not http://mydomain.com will be redirected to that domain.

2 - Change public IP without downtime

Overview

In Jelastic PaaS you can easily switch IP-addresses by yourself without any downtime.

Attach new IP-address

1. Expand your environment. If you hover over your Public IPv4-address, an icon for attaching or detaching IP-addresses will appear.

2. Attach a new IP by raising the number of IP-addresses to 2.

3. Verify that your node has been assigned two IP-addresses.

Update DNS-records

4. Update relevant DNS records at your DNS provider to point to the new IP address.

Please keep in mind that your DNS change can take up to 24 hours before it’s completely propagated worldwide. You can verify your DNS propagation here: DNS Checker

Detach IP-address

Caution: In this next step we will go through how to detach an IP-address. Once you are ready to remove the IP-address, proceed to the next step.

5. Press the Detach IP button to the right of the IP address that you wish to remove from your environment.

6. Confirm the detachment.

That’s it! If something in this guide is unclear or if you have any questions, feel free to contact us.

3 - Copy a SQL database

Overview

This guide will walk you through the procedure of copying a SQL database between environments using the Jelastic GUI.

Export the database

1. Open up phpMyAdmin on the source environment by clicking the icon as shown below

2. Export the database by first choosing the database to the left, in our case example, and then click on Export on the top navigation bar. Make sure to check the box where it says “Save on server in the directory /var/lib/jelastic/phpMyAdmin/save” and then click “Go”.

4. Now you have exported the database.

Share folder between environments

1. Find the configuration wrench on the SQL Databases source node.

2. Go to folder /var/lib/jelastic/phpMyAdmin. Click the cogwheel on the save folder as shown on the image below and choose Export

3. Make sure to choose the correct target container where your target SQL database is at.

4. Make sure to use the path /var/lib/jelastic/phpMyAdmin/upload

5. Now the target environment should have access to a folder on the source environment.

Import the database

1. Open up phpMyAdmin on the target environment.

2. In order to import the database, we need to create it beforehand as shown below.

3. Since you have mounted the source environments save folder to the target environments upload folder, you have access to the sql files there. So click on “Select from the web server upload directory /var/lib/jelastic/phpMyAdmin/upload/” and click Go to import it.

4. At this time, you should have a successful import.

Cleanup - unmount the shared folder

1. When you are done exporting and importing databases, you should remove the shared folder. Click on the wrench on the target environments database node.

2. You should see the upload folder in your Mount Points folder below to the left. Click the cogwheel and unmount, as shown in the image below

You should be all set!

4 - Copy files between environments

Overview

This guide will help you getting started with moving files between environments using the Jelastic GUI.

Export directory

1. Find the configuration wrench on the Application Servers source node.

2. Go to folder /var/www/webroot (via favorites to the left). Click the cogwheel on the ROOT folder as shown on the image below and choose Export

3. Make sure to choose the correct target container where your target Application Server is at.

4. Here we use the path /var/www/webroot/FROM_SOURCE which will create and mount this folder on the source environments Application Server.

Copy files

5. Click the configuration wrench on the target environment’s Application Server.

6. To the left, click the cogwheel and click Copy Path, which will copy the full path location to your clipboard.

7. Click on the terminal icon to engage the Web SSH terminal

8. In the terminal you should write cd then paste previously copied path /var/www/webroot and then enter. After that you should see the folder FROM_SOURCE executing ls -l as shown on the image below.

9. Now you should be able to copy files as shown below. Using the --verbose flags gives you this output.

10. You can confirm that the files been copied by browsing to that folder in the GUI.

Clean up

11. Unmount the exported directory on the target application server as shown below.

5 - Enable IPv6

Overview

This guide will help you enable IPv6. Remember that you might need to configure your application to listen on IPv6.

Enabling IPv6

1. Expand your environment. If you hover over “Public IP”, an icon for attaching or detaching IP-addresses will appear.

2. Here we can choose to attach IPv4-addresses or enable Public IPv6 by switching the toggle to “ON”.

3. Verify that your environment have been assigned a new IPv6-address.

That’s it! If something in this guide is unclear or if you have any questions, feel free to contact us.

6 - Enable X11-Forwarding on VPS

CentOS

Note: This was tested on CentOS 7.9 but should apply to all available versions. Some minor differences may be present.

1. Install Xauth with yum install xorg-x11-xauth
2. Make sure X11Forwarding is enabled by running grep X11Forwarding /etc/ssh/sshd_config, the output should look like: X11Forwarding yes If the output is X11Forwarding no, edit the value in the sshd config with vim /etc/ssh/sshd_config and restart sshd service sshds restart
3. Connect to the VPS ssh -X user@ip
4. Install an X application to verify that it works (for example: yum install xclock and then run it with xclock)

Ubuntu

Note: This was tested on Ubuntu 20.04 but should apply to all available versions. Some minor differences may be present.

On a Ubuntu 20.04 VPS the package xauth is already installed by default.

1. Make sure X11Forwarding is enabled by running grep X11Forwarding /etc/ssh/sshd_config, the output should look like: X11Forwarding yes If the output is X11Forwarding no, edit the value in the sshd config with vim /etc/ssh/sshd_config and restart sshd service sshds restart
2. Connect to the VPS ssh -X user@ip
3. Install an X application to verify that it works (for example: apt install xarclock and then run it with xarclock)

Debian

Note: This was tested on Debian 11.2 but should apply to all available versions. Some minor differences may be present.

On a Debian 11.2 VPS the package xauth is already installed by default.

1. Make sure X11Forwarding is enabled by running grep X11Forwarding /etc/ssh/sshd_config, the output should look like: X11Forwarding yes If the output is X11Forwarding no, edit the value in the sshd config with vim /etc/ssh/sshd_config and restart sshd service sshds restart
2. Connect to the VPS ssh -X user@ip
3. Install an X application to verify that it works (for example: apt install xarclock and then run it with xarclock)

7 - FAQ

Q: We would like to explore migration options already now. How should we think?

A: Elastx provides a range of compute, database and other infrastructure products that can cover your needs. There is specific packaging in Virtuozzo PaaS which we - at this point in time - cannot substitute directly. However, we will present options later this year.

Q: We run one or a few VPS in Virtuozzo PaaS. Can we simply migrate to OpenStack IaaS?

A: Yes, however we strongly recommend that you migrate with the approach of rebuilding your workloads in OpenStack IaaS and migrate data there prior to shifting over your customer traffic. This way you may ensure that things are patched to the latest versions and tests are successful. Contact us at support@elastx.se and we will set up an OpenStack IaaS project for you.

Q: We love Virtouzzo PaaS. Why do you deprecate the product?

A: At Elastx, we pride ourselves that robustness and security are parameters we value before others such as for example abundance of features or the lowest possible price point. Continuously we evaluate and challenge the architecture of Elastx Cloud Platform to be able to deliver on our commitments.

Another piece of the puzzle is that technology never stops evolving.

For these reasons we have made a strategic choice to deprecate Virtuozzo PaaS and replace this with our already existing products and those planned before end of life. This as we are confident that we can provide alternatives for most customers and use cases with additional focus on the mentioned parameters.

Q: When can we expect alternative migration paths and how will this be communicated?

A: Alternative migration paths to our Elastx IaaS, CaaS and DBaaS products are proven for several customers already. We are investigating replacement options that are more one to one as well, however these will not be launched until next year. There will be corresponding announcements as we near launch.

Q: What are the actual products and services that will be deprecated?

A: Virtuozzo PaaS service according to the specifications in this link

Q: How can we leverage Elastx other products and services to deliver the same result?

A: The answer to this question all lies within the scope and details of your environment setup, workloads and applications. In general our Elastx IaaS, CaaS and DBaaS products will be possible to leverage in order to deliver the same result. However, there are specific services that are not available as built-in components as they are in Elastx PaaS.

Q: Will the prices differ when we run Elastx IaaS, CaaS and DBaaS compared to Virtuozzo PaaS?

A: In general, the price points match each other as the product billing is built on consumption per use. There are pricing lists available to review and approximate the costs to run your services on these products.

Q: Do you offer consulting services to help us migrate?

A: Yes. You are welcome to contact us through support@elastx.se and we will certainly assist you with consultative inquiries around for example technical design, scoping and migration activities supported by our Cloud Architect resources.

Q: What will happen on the end of life date - will all data be removed or is it backed up in some way?

A: Elastx will disable the service but store customer data for an additional 180 days before we permanently remove it from our infrastructure. You are welcome to request a copy.

Q: Do you have any case studies with more details that we can read up on?

A: Please contact us with a description of your particular case and we will see whether we have something that matches to share.

8 - Force HTTPS on Apache behind Nginx load balancer

Edit httd.conf

Add the following configuration in the Apache configuration file httd.conf.

<VirtualHost *:80>
...
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</VirtualHost>

9 - Force HTTPS with Tomcat

Overview

This guide describes how to make Tomcat force all traffic over HTTPS.

Tomcat Configuration

On the Tomcat node, edit the web.xml file and add the following in the <web-app *> section.

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Protected Context</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <!-- auth-constraint goes here if you require authentication -->
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

With this, Tomcat will attempt to redirect any HTTP request to the specified context and instead use the HTTPS Connector, and as such never serve it under HTTP.

If you are using the shared Jelastic SSL certificate or if you are using a load balancer in front of your Tomcat node, you will need to make the below changes. This is to make Tomcat understand X-Forwarded-Proto by adding the following text in the Tomcat server.xml <Engine> section.

    <Connector port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="443" />

We also need to adjust the redirectPort on the connector. It should redirect users to 443 (and not 8443).

Note: 8443 is the internal port Tomcat listens on, but the Jelastic resolver pushes traffic to 443 and it’s translated to the correct Tomcat port for you automatically. So 443 is the correct port for HTTPS requests.

Edit the server.xml file and change the connector redirect to port 443.

    <Connector port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="443" />

Restart the Tomcat node and it should be done.

10 - Log real client IP behind a proxy

Overview

This guide will demonstrate how to make your web server log your client’s real IP instead of the proxy’s. This is applicable both if your web server is behind your own proxy or our Jelastic resolver.

Nginx Configuration

Replace $remote_addr with $http_x_real_ip in your nginx.conf where the log format is defined.

This is what is should look like:

    log_format  main  '$http_x_real_ip:$http_x_remote_port - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      '"$host" sn="$server_name" '
                      'rt=$request_time '
                      'ua="$upstream_addr" us="$upstream_status" '
                      'ut="$upstream_response_time" ul="$upstream_response_length" '
                      'cs=$upstream_cache_status' ; 

And this is the default value, note that the only change is on the first row.

    log_format  main  '$remote_addr:$http_x_remote_port - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      '"$host" sn="$server_name" '
                      'rt=$request_time '
                      'ua="$upstream_addr" us="$upstream_status" '
                      'ut="$upstream_response_time" ul="$upstream_response_length" '
                      'cs=$upstream_cache_status' ;

Your nginx access log will now contain the client’s real IP instead of the proxy’s.

Apache Configuration

For Apache you’ll need to change the LogFormat in your httpd.conf to the following:

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b" common

The default values to be replaced are:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common

Done, your Apache access log will now contain the client’s real IP instead of the proxy’s.

11 - Migrate an environment to another provider

Overview

Virtuozzo PaaS at Elastx reaches end of life 2026-12-31. If you want to stay on the same platform technology rather than rebuild on Elastx IaaS/CaaS, your environment can be moved to another provider in the Virtuozzo Cloud Union. This guide uses beebyte (app.paas.beebyte.io, Sweden) as the target, but the procedure is the same for any Virtuozzo/Jelastic installation.

There are two routes:

Plan for route B as your baseline and treat route A as the shortcut. Do not delete anything at Elastx until the target environment is verified and serving traffic.

Before you start

1. Check the platform versions

An exported environment can only be imported into an installation of the same or a higher platform version.

The target is newer than the source, so this direction is allowed. Versions change — confirm the current numbers on the Virtuozzo Cloud Union partner pages before you start, and re-check if the migration is planned for a later date.

2. Inventory the environment

Write down everything that is not application data, because most of it does not travel with an export and has to be recreated by hand at the target:

• Node types and counts, cloudlet limits per node, and which nodes are scaled horizontally
• Public IPv4/IPv6 addresses (these are not transferred — the target gets new ones)
• Custom domains and their DNS records, plus current TTLs
• SSL certificates (built-in Let’s Encrypt add-on vs. custom certificates)
• Environment variables, cron jobs, and firewall rules per node
• Files edited through the Configuration Manager (nginx.conf, php.ini, server.xml, …)
• Database users, grants, and passwords
• Add-ons installed from the Marketplace
• Outgoing mail setup, and anything that depends on the current source IP being allow-listed by a third party

3. Create the target account

Register at beebyte (or your chosen provider) and confirm the quotas on the new account are large enough for the topology you are about to import — cloudlet limits, disk, and number of environments.

Route A: native Environment Export / Import

Known caveat for exports from Elastx

Virtuozzo’s own documentation states that the export/import feature requires the source platform to have port 7979 reachable, and it explicitly names Elastx as an installation whose exported environments therefore may not be importable elsewhere:

For the Environment Export / Import feature to work properly, the initial hosting provider platform (i.e., you are exporting the environment from) should have the 7979 port opened […] Thus, depending on a particular provider’s configurations, exported environments from some of our partners’ platforms (Elastx and Everdata in particular) can’t be imported to other PaaS installations.

— Environment Export, Virtuozzo docs

The manifest itself contains links to the archives holding your private data; it is those downloads that need port 7979 during import. Consequences:

• A topology-only export is still portable, and is useful as a blueprint even if the data transfer is blocked.
• Before committing to route A, test it with a small throwaway environment: export it with all options ticked, import it at the target, and confirm the data actually arrives.
• If the import fails on fetching data, contact support@elastx.se and ask whether port 7979 can be opened for your migration window, and use route B meanwhile.

Export at Elastx

1. The environment must be in Running status.
2. In the dashboard, click Settings for the environment you want to move.
3. Go to the Export section and click Export.
4. In the Environment Export dialog, tick all three options for a fully identical copy:
   • Topology Settings — node layout and configuration (mandatory, always on)
   • Private Data — application files and database contents
   • Configuration Files — everything reachable via Configuration Manager, plus GIT/SVN project settings (repository URLs, credentials, attached private SSH keys)
5. Click Export and wait. Note what will not come along:
   • Data from Elastic VPS, Maven, Docker and Windows-based containers is not exported. These nodes appear in the imported topology but are created from scratch — reconfigure them manually.
   • Exporting an NGINX node (load balancer or application server) briefly stops and restarts that node to take a dump. Do this outside peak hours.
6. When the export finishes, a new entry appears under Exported Environment Copies, named after the export date/time. Click it to download the .json manifest, or right-click to copy a direct URL to it. You also get an email with a link to the list.

Exported copies are stored in your disk space and are billed like any other storage. Delete them with the red cross button once the migration is done.

Import at beebyte

1. Log in to the target dashboard (app.paas.beebyte.io) and click Import at the top.
2. Choose a tab:
   • Local File — browse to the .json you downloaded
   • URL — paste the direct manifest URL you copied at Elastx
   • JPS — the built-in editor, if you need to hand-edit the manifest first
3. Click Import. The confirmation window shows the source platform and export date. Fill in:
   • Environment — the domain name of the new environment
   • Display Name — optional alias
   • Region — if the provider offers several
4. Click Import and wait for the environment to be created and configured. You can minimize the window; it continues in the background.
5. Check your email at the target provider for the new hostname and the generated node credentials — these are new, the old passwords do not follow.

If the import fails, open Import > JPS > View Logs at the target for the error.

Route B: manual rebuild and data migration

Use the exported .json as the blueprint even if you cannot import it — it is readable JSON and describes the full topology.

1. Recreate the topology

Build the same node layout in the target’s topology wizard: same engines and same or newer engine versions (PHP, Java, Node, database), same cloudlet limits, same horizontal scaling. Install the same Marketplace add-ons.

2. Move application files

Both platforms expose an SSH gateway on port 3022, so you can copy directly between them:

Upload your public SSH key under Account Settings > SSH Keys on both platforms, then either pull the data down to a workstation and push it up, or copy node-to-node:

# From a machine with access to both, per node:
ssh -p 3022 <source-node-uid>@gate.jelastic.elastx.net \
  "tar czf - -C /var/www/webroot ROOT" > webroot.tar.gz

cat webroot.tar.gz | ssh -p 3022 <target-node-uid>@gate.paas.beebyte.io \
  "tar xzf - -C /var/www/webroot"

The node UID is shown in the dashboard next to each container (it is also the SSH username). rsync -az -e 'ssh -p 3022' works too and is better for repeated syncs — run it once up front and again at cutover to catch the delta.

Alternatively, use the Web SSH terminal and the file manager behind the configuration wrench in either dashboard. Note that the Elastx guides for copying files and copying a SQL database use mount points between environments — that only works within one platform, not across providers.

3. Move databases

Dump at the source, restore at the target. Over the SSH gateway, for MySQL/MariaDB:

ssh -p 3022 <db-node-uid>@gate.jelastic.elastx.net \
  "mysqldump -u <user> -p<password> --single-transaction --routines --triggers \
   --databases <db1> <db2>" | gzip > dump.sql.gz

zcat dump.sql.gz | ssh -p 3022 <target-db-uid>@gate.paas.beebyte.io \
  "mysql -u <user> -p<password>"

Use pg_dump/pg_restore for PostgreSQL and mongodump/mongorestore for MongoDB. Recreate database users and grants separately — they are not always part of the dump. For small databases phpMyAdmin’s export/import works, but it is fragile above a few hundred megabytes; prefer the CLI.

4. Reapply configuration

Node passwords, IPs, and hostnames all change. Go through the inventory from step 2 and reapply: Configuration Manager files, environment variables, cron jobs, firewall rules, SSL certificates, and any connection strings or config files in your application that reference the old hostnames, IPs, or database credentials.

Cutover

1. Lower DNS TTL on the affected records to 300 seconds at least 24–48 hours before the switch, so a rollback is fast.
2. Test on the target’s own hostname first (<env>.paas.beebyte.io), with the application fully configured.
3. Re-sync the delta: run the file rsync and a fresh database dump immediately before the switch, ideally with the source application in read-only or maintenance mode so nothing is written after the final dump.
4. Attach custom domains and certificates at the target, then switch DNS.
5. Update anything IP-bound: third-party allow-lists, payment providers, SMTP relays, and monitoring all need the new public IP.
6. Keep the Elastx environment running — stopped, but not deleted — until you are confident. Virtuozzo’s documentation recommends the same: do not delete the original of an exported environment until the copy is verified at the target.

After the migration

• Delete the exported copies at Elastx to stop paying for their storage.
• Stop and then delete the source environment once you are done. Removing running environments is also a prerequisite for closing the Elastx PaaS account.
• If you discover a gap after the EOL date: Elastx disables the service but stores customer data for an additional 180 days before permanent removal, and you can request a copy. See the EOL FAQ.

Checklist

• Target platform version is same or higher than Elastx’s
• Target account created with sufficient quotas
• Environment inventory documented (IPs, domains, certs, env vars, cron, firewall, grants)
• Route A validated with a throwaway environment, or route B chosen
• SSH keys uploaded on both platforms
• Topology recreated / imported and verified
• Files migrated
• Databases migrated, users and grants recreated
• Configuration and connection strings updated for new hostnames/IPs/credentials
• Application tested on the target hostname
• DNS TTL lowered
• Final delta sync done with source in maintenance mode
• Domains and SSL attached at target, DNS switched
• Third-party IP allow-lists updated
• Source environment kept intact until verified, then removed
• Exported copies deleted

Need help?

Elastx offers consultative assistance with migration scoping and design — contact support@elastx.se. For questions about the target platform, contact the receiving provider.

12 - Nginx LB HTTP to HTTPS redirect

Overview

If you have an nginx load balancer in you environment and want to redirect all requests to https then you can add the following configuration.

nginx configuration

On the nginx load balancer node select config and create a new file under conf.d named redirect.conf. Add the following configuration to the file, save it and restart nginx.

server {
       listen *:80 default_server;
       access_log /var/log/nginx/redirect.access_log main;
       error_log /var/log/nginx/redirect.error_log info;
       location / {
         rewrite ^ https://$host$request_uri? permanent;
       }
}

13 - Nginx redirect to HTTPS

Overview

If you have enabled https, have a public IP and want to redirect all traffic from http to https you can change the “/ location {}” section in nginx.conf to the following.

location / {
  rewrite ^ https://$host$request_uri? permanent;
}

If your webserver is located behind a proxy, loadbalancer or WAF (that sends x-forwarded headers) you can simply use the below snippet instead.

if ($http_x_forwarded_proto != "https") {
  rewrite ^ https://$host$request_uri? permanent;
}

14 - Node.JS NPM Module Problems

Overview

If you have problems with installing node modules via npm and get “unmet dependency” errors then this guide might help.

Solution

Try to remove all installed modules, clear the npm cache and reinstall. Log in to the node with ssh and run the following commands:

cd /home/jelastic/ROOT

npm cache clean --force

rm -r node_modules

npm install

15 - PHP max upload file size

Overview

This guide demonstrates how to increase (or decrease) the PHP max upload file size. We’ll need to both configure PHP and then the web server if you’re running nginx.

PHP Configuration

In php.ini, find the rows containing upload_max_filesize and post_max_size and change their values to the desired amount.

By default they will look something like this, depending on what type of node you’re running their values might differ:

upload_max_filesize = 100M
post_max_size = 100M          ; Maximum size of POST data that PHP will accept.

Continue with the web server configuration below.

Nginx Configuration

If you are running nginx you will need to edit (or add if it’s missing) the following row with the desired value in the http {} block in nginx.conf.

client_max_body_size 32m;

Restart the node for the changes to take effect.

16 - Redirect nginx

Overview

If you want to make sure all traffic only uses your preferred domain name you can create a new server {} block that redirects to the preferred domain name.

Edit nginx.conf

On your nginx node select config and edit the nginx.conf file. In this example we’ll redirect my-site.jelastic.elastx.net to https://my-domain.tld

server {
    server_name my-site.jelastic.elastx.net;
    listen 80 default_server;
    return 301 https://my-domain.tld/$request_uri;
}

17 - Restrict phpMyAdmin access

Overview

If you want to limit access to the database phpMyAdmin you can use a Apache access rule.

Configuration

1. In the Virtuozzo PaaS GUI, select “Config” on the database node.

2. Edit the file /conf.d/phpMyAdmin-jel.conf and make sure your <Directory /usr/share/phpMyAdmin/> looks like this. Edit the IP to the IP that should be granted access.

<Directory /usr/share/phpMyAdmin/>
     SetEnvIf X-Forwarded-For ^xxx\.xxx\.xxx\.xxx env_allow_1
     Require env env_allow_1
     Require ip xxx.xxx.xxx.xxx
     Require all denied
</Directory>

Note: Make sure to edit the IP in the example to your desired value

3. Restart the environment or contact support and we can reload the Apache configuration for you.

18 - SMTP on port 25 not working

Overview

By default we block traffic to internet on tcp port 25. We do this to prevent abuse, mail abuse is very common and we do our best to prevent this from happening.

Alternatives

If you want to send e-mail from our platform we recommend using our Mail Relay service. All major SMTP services offer their service on other ports than port 25.

This way you can get an automated reliable SMTP service that is very cost effective.

You can read more about our Mail Relay offering here. Contact us if you have any other questions.