Short answer: only individuals who have a valid invitation.
In detail: xHOSTING is a closed, community-based system that is not public and does not allow automatic registration. Joining is only possible with a valid invitation issued by an existing member with appropriate permissions. The goal is to preserve the quality, security, and sustainability of the community.
An invitation can only be received from an existing xHOSTING member.
The system does not offer a public application form or automatic registration. Invitations are granted to individuals whom an authorized member personally considers suitable for complying with community rules and responsible resource usage.
Only xHOSTING members with the appropriate permissions may send invitations.
The right to invite is not a default right; it is tied to a specific status and community conditions. Whether a member has active invitation rights depends on the conditions defined in the community policy and on decisions made by the xHOSTING operators.
Yes, the number of invitations is limited.
An eligible member may use a defined number of invitations, which is currently: 1 invitation. Invitation rights are not cumulative, do not renew automatically, and each invitation is permanently consumed once accepted. The purpose of this limitation is to protect resources and prevent overselling.
Issuing an invitation carries responsibility.
The inviting member assumes responsibility for ensuring that the invited person becomes familiar with and complies with xHOSTING rules, especially the Code of Conduct and the Acceptable Use Policy (AUP). In cases of repeated or serious abuse, invitation rights may be restricted or revoked.
In the event of a violation, xHOSTING will take action depending on the severity of the case.
This may include a warning (WARN), service restrictions, or even termination of membership. In cases of serious or repeated violations, the invitation rights or membership of the inviting member may also be affected.
Yes, invitations can be revoked and may have limited validity.
xHOSTING reserves the right to revoke an invitation for technical, security, or community-related reasons. Unused invitations may expire or become invalid if the inviting member loses their invitation rights.
No. Invitations may neither be sold nor transferred.
An invitation applies exclusively to the person for whom it was originally intended by the authorized member. Selling, exchanging, or transferring invitations to third parties constitutes a serious violation and may result in immediate sanctions.
The closed, invitation-only nature of xHOSTING serves to protect the quality, security, and sustainability of the community.
The invitation model allows community size and resource usage to remain controlled and ensures that members are aware of and accept the community rules. This reduces the risk of abuse, overload, and legal issues.
xHOSTING is not a classic hosting provider but a community-based technical infrastructure.
There is no public package offering, SLA, customer support prioritization, or guaranteed availability. The system does not operate on a commercial basis but relies on community contributions and voluntary operation.
No, xHOSTING is a community initiative, not a commercial hosting service.
Community (free) services are not considered commercial hosting or electronic communications services. Certain separate services (such as domain registration) may be available as paid services under a separate legal relationship.
No, membership itself is not subject to a fee.
The operation of xHOSTING is supported by voluntary community contributions. These do not constitute purchases or subscriptions and do not grant automatic rights or guarantees.
Community-based operation means that xHOSTING does not function as a customer–service provider relationship.
Members jointly contribute to maintaining the system, comply with community rules, and use resources responsibly. The emphasis is on trust, cooperation, and sustainability.
Members gain access to the xHOSTING community infrastructure.
This may include web hosting, email services, databases, SSH access, and the xHOSTING Control Panel (XCP). Exact features depend on current resource capacity and configuration.
Membership may be terminated due to rule violations, abuse, or a community decision.
Serious or repeated breaches of rules, violations of the AUP, or behavior that endangers community operation may result in termination of membership.
Yes, membership can be terminated voluntarily at any time.
A member may request account closure, after which access to community (free) services will cease. Termination does not entail obligations or sanctions.
Access to community services is terminated.
After termination, xHOSTING may retain data for a limited period for technical purposes, after which it will be permanently deleted. Paid services (such as domain services) may remain available under a separate legal relationship.
xHOSTING rules and policies are publicly available on the official website.
These include in particular the Policy, the Acceptable Use Policy (AUP), the Privacy Policy, and the Cookie Policy. These documents are accessible before joining and throughout the entire membership period and form the basis of community membership.
xHOSTING expects polite, respectful, and trust-based behavior from its members.
Members must comply with the policy, respect others’ resources and rights, and refrain from any activity that could endanger the operation, reputation, or security of the community.
A WARN is an official warning issued by the Operators in cases of rule violations.
A WARN may be issued for violations of the Acceptable Use Policy, behavior that breaches community norms, abuse of resources, or repeated minor infractions. The purpose of a WARN is not punishment, but awareness and protection of the community.
Community decisions are not authority-based or official legal decisions.
The Operators may provide an opportunity for discussion or consultation; however, decisions related to membership, moderation, or community operation do not qualify as appealable administrative rulings.
Yes, community behavior can directly affect certain permissions.
Compliant and cooperative conduct may be a prerequisite for obtaining or retaining rights such as invitation privileges. In the case of an active WARN, abuse, or repeated rule violations, certain permissions may be restricted or revoked.
The purpose of the XBASIC package is to provide a stable, transparent, and unified technical foundation for all members of the xHOSTING community.
This package does not compete with commercial hosting services; instead, it offers a clearly defined, sustainable set of resources suitable for running websites, email accounts, and basic online projects while respecting community principles.
The XBASIC package is recommended for those seeking reliable but non-commercial hosting.
It is particularly suitable for personal projects, presentation websites, smaller web applications, email usage, learning or development purposes, and for users who accept the principles of community operation and shared resources.
Currently, xHOSTING provides a single unified community package: XBASIC.
This is a deliberate decision: a unified package supports transparent operation, prevents overload, and ensures fair distribution of community resources. Any future changes or new structures will be designed with community needs and sustainability in mind.
The XBASIC package has fundamentally fixed limits.
Certain permissions or technical options—such as special access—may be enabled upon request on a case-by-case basis, provided they do not endanger community operation. Traditional package upgrades or scaling are not part of the system.
The community principle means that xHOSTING infrastructure is shared by members with consideration for one another.
Resources are not guaranteed, isolated capacities but shared technical capabilities. Therefore, members are expected to use services as intended, avoid excessive load, and respect the interests of the community.
The 10 GiB of storage in xHOSTING is used collectively for website files, databases, email accounts, and related data.
In practice, this is sufficient for multiple average websites, CMS installations (e.g., WordPress), images, documents, and email accounts. Actual usage depends on stored content and email traffic.
10 TiB of monthly data transfer is an exceptionally high amount for a community hosting package.
It is more than sufficient for serving small to medium traffic websites, file downloads, and email communication. The purpose of the limit is not strict restriction but filtering out extreme, abusive traffic.
xHOSTING does not apply automatic speed reduction or immediate suspension upon reaching the traffic limit.
If an account consistently or unjustifiably generates excessive data transfer, the Operators may contact the Member on a case-by-case basis and, if necessary, introduce temporary restrictions to protect the community.
If storage usage reaches the maximum 10 GiB limit, no new data can be added to the account.
In such cases, it is the Member’s responsibility to delete or optimize existing data (e.g., remove old backups or emails). In cases of persistent overuse, xHOSTING may temporarily restrict certain functions to maintain system stability.
The hosting space is intended primarily for files required to operate websites, databases, email data, and related content.
Storing content that is illegal, infringes copyright, is harmful (e.g., malware), or unjustifiably burdens community resources is prohibited. Detailed restrictions are defined in the Acceptable Use Policy (AUP).
Within the XBASIC package, a Member may use up to a total of 3 separate domain names in the xHOSTING system.
These may serve as independent websites or domains with distinct purposes. The limit aims to ensure balanced use of community resources rather than impose artificial restrictions.
Yes. xHOSTING fully supports the use of privately owned domain names.
The domain may be registered elsewhere; in such cases, DNS settings must be pointed to the values provided by xHOSTING. Domain management and DNS editing are available through the XCP (xHOSTING Control Panel).
A subdomain is a separate address under a main domain, such as blog.example.com or dev.example.com.
The XBASIC package allows the creation of up to 3 subdomains, each assignable to a separate directory or application within the XCP. The www prefix also counts as a subdomain and is created automatically when the main domain is added. Therefore, two additional subdomains can be freely created per main domain.
By default, the XBASIC package allows the use of 3 domains.
Adding further domains is only possible based on community and technical considerations, subject to individual approval. xHOSTING does not operate on an overselling basis; therefore, expansion is not automatic.
Yes. Deleting or replacing the main domain is permitted via the XCP (xHOSTING Control Panel).
Before performing the operation, it is the Member’s responsibility to back up associated websites, email accounts, and data. After deletion, related services may cease or require reconfiguration.
Within the XBASIC package, up to 6 separate email accounts can be created.
Each email account has its own mailbox, login credentials, and allocated storage. The 6 email addresses mean that a total of 6 active email addresses can be used within the system.
An email account is a technical mailbox with a username, password, and storage.
An email address is a reachable address (e.g., info@domain.com) that points to an email account or forwards messages to other addresses.
Multiple email addresses (aliases) can be assigned to a single email account; however, the XBASIC package allows a total of 6 addresses.
Yes. The XBASIC package supports the catch-all function.
Catch-all allows all emails sent to non-existent addresses of a domain to be delivered to a specified email account. This setting can be configured in the XCP (xHOSTING Control Panel).
Yes. The XBASIC package allows creating up to 6 email forwards.
Forwarding allows emails arriving to an email address to be automatically forwarded to another address (for example, to an external email provider), even without creating a mailbox.
Yes. xHOSTING’s email service is fully compatible with standard email protocols.
Email can be used with external clients (e.g., Outlook, Thunderbird, Apple Mail) via IMAP/POP3 and SMTP. The required server details are available in the XCP interface.
In the XBASIC package, you can create up to 3 databases in the XCP (xHOSTING Control Panel - XCP).
This limit applies to the number of databases (e.g., site1_db, site2_db, wp_db), not to the number of tables. A database may contain any number of tables, as long as it fits within the storage and resource limits.
In short: xHOSTING provides a MySQL/MariaDB-based database system, fully compatible with most common PHP-based web applications.
Typical examples include:
The exact engine/version depends on server-side configuration, but the environment follows standard LAMP/LEMP stack requirements.
Yes. You can install WordPress and other database-driven CMS platforms (e.g., Joomla, Drupal) as long as they comply with the AUP and the package’s resource limits.
Typically you will need a database, a database user, and to upload the files (via the XCP file manager or FTP). The PHP limits (e.g., 256M memory_limit, 128M upload_max_filesize) can also help with larger installations.
Yes. In the XBASIC package, the “Applications” permission is enabled: it provides access to the XCP application installer feature, which can simplify installing several popular web applications.
The exact list of available applications is shown in the XCP and may change over time.
Yes. You can also run a custom web application if you comply with xHOSTING rules (especially the AUP) and the application does not place a disproportionate load on community resources.
The XBASIC package supports a typical web stack (FTP, PHP, SSH, database), so custom PHP projects, static sites, and applications running in a controlled environment can be implemented.
In the XBASIC package, you can create up to 3 separate FTP users in the xHOSTING Control Panel (XCP).
Each FTP user has their own username and password, and can be used separately to upload, modify, or delete files. This is useful, for example, if you want to separate multiple websites, subdomains, or developers.
Yes. The XCP (xHOSTING Control Panel) includes a browser-based file manager.
The file manager allows, among other things:
This is especially useful if you want to make a quick change without using an FTP client.
Yes. In the xHOSTING environment, an encrypted connection can also be used to access files.
If SSH is enabled for your account, FTP users can also connect via SFTP, which uses the SSH protocol, so the traffic is encrypted.
This is a recommended solution on public networks and when handling sensitive data.
Yes. In the XCP, FTP user permissions can be restricted at directory level.
For example, you can set an FTP user to:
This increases security and helps prevent accidental or intentional changes affecting other sites.
The xHOSTING Control Panel (XCP) enables parallel use of multiple PHP versions.
The exact versions available depend on the current system state, but typically you can choose from:
The PHP version can be set per domain or per subdomain, so different websites can run according to different requirements.
Yes. The XCP provides the ability to customize key PHP directives within the limits defined by the package.
In the XBASIC package, for example, the following values are available:
memory_limit: 256 MBmax_execution_time: 120 secondspost_max_size: 128 MBupload_max_filesize: 128 MBChanging these settings is done via the XCP; there is no need to manually edit php.ini.
open_basedir and disable_functions are restrictions used to run PHP securely.
open_basedir:
disable_functions:
The XCP displays these values transparently so the user is aware of the active restrictions.
ondemand pm is one of the operating modes of PHP-FPM (Process Manager).
In ondemand mode:
This mode is especially suitable for low to medium traffic websites and fits well with xHOSTING’s sustainable resource management principles.
These are parameters that control how PHP-FPM operates.
pm.max_children:
pm.max_requests:
These values ensure a balance between stability, performance, and community resource usage.
Yes. The XBASIC package includes SSH access, enabling advanced users to work from the command line.
SSH access primarily serves development, maintenance, and administrative purposes, and is managed through the xHOSTING Control Panel (XCP).
A restricted SSH environment means that the SSH session is restricted exclusively to the user’s own directory.
The purpose of this is:
Despite the restriction, the most common development and operational tasks can be performed.
Yes, within the restricted SSH environment, running your own commands is allowed.
Typically you can use:
System-level commands, actions affecting other users’ resources, or starting background services are not permitted.
In short: not by default, but individual requests may be reviewed in justified scenarios.
Remote access is disabled for security reasons. However, for development or migration purposes, limited and temporary access may be considered upon request.
Each request is evaluated individually, taking into account:
xHOSTING is primarily optimized for local database access within the hosting environment.
Yes. In certain cases, remote database access can be requested subject to individual assessment.
Approval is always based on technical and security considerations, and it is not automatic.
The goal is to ensure that special needs can be met without jeopardizing xHOSTING’s community-based operation.
Yes. xHOSTING’s system creates automatic backups to reduce the risk of data loss.
However, it is important to note that these backups do not qualify as a guaranteed, SLA-based service. The backups primarily serve technical protection and do not replace your own backup strategy. Partial or full restoration from central backups can be performed by the Technical Operator upon separate request, but this is a paid service.
Yes. The XBASIC package allows setting up your own backup destination via the xHOSTING Control Panel (XCP).
Using your own backup destination is strongly recommended, because it gives the Member full control over backups. Partial or full data restoration from your own backup destination can be performed by the user free of charge in the XCP interface.
xHOSTING supports multiple backup options, including:
This allows backups to be stored on an external server, NAS, or cloud-based storage.
Yes. Backups made to your own backup destination can be restored independently, based on the user’s decision and schedule.
For automatic, system-side backups, the ability to restore is subject to technical limitations, is not guaranteed in all cases, and is a paid service.
Therefore, xHOSTING’s recommendation is: for all important data, use your own external backup solution.
xHOSTING operates as a closed, community-based system where multiple Members share the same infrastructure. Therefore, security is not only an individual matter but also a community interest.
The goal of package design is to ensure that every Member can work in a stable, predictable, and secure environment, without any single user’s activity endangering the entire system.
xHOSTING applies protection mechanisms at multiple levels, including:
Together, these help prevent overuse, abuse, and security risks.
With community-based hosting, the focus is on shared responsibility and sustainability, rather than serving individual overuse.
While a commercial provider often operates with overselling and an SLA, xHOSTING’s model is built more on:
which enables more stable and secure operation in the long run.
Respecting resource limits ensures that every Member receives equal and predictable access to the community infrastructure.
If a Member exceeds or ignores these limits, it can:
The foundation of xHOSTING’s operation is conscious, responsible resource usage.
xHOSTING packages are intentionally designed with conservative default settings. The goal is to preserve the stability, security, and long-term sustainability of the community infrastructure.
Some features—such as remote database access or special runtime capabilities—may involve increased risk or resource load, therefore they are not automatically available to every Member.
Features “available upon request” are options that are not part of the base package, but may be enabled in justified cases, based on individual assessment.
This means the Member may justify the need for the feature (e.g., for development, testing, or compatibility reasons), and xHOSTING operations will assess whether enabling it would not endanger the community operation. In this case, the Technical Operator will monitor the resource usage of the enabled feature with special attention and its impact on the community infrastructure.
When assessing individual requests, the following key factors are considered:
The purpose of assessment is not to obstruct, but to maintain responsible, community-friendly operation.
Yes, an individual request can be rejected if fulfilling it would:
Rejection is not a sanction, but a technical decision aimed at protecting community operation.
Perl/CGI is disabled by default because it is a technology based on an older execution model that can pose increased security and resource risks in modern multi-user environments.
xHOSTING’s community infrastructure is primarily optimized for isolated, sandboxed runtime environments. Perl/CGI, by contrast, has characteristics that are difficult to align with community resource protection.
The Perl/CGI environment may carry the following risks:
In a community-based hosting environment, these risks can affect not only the given Member, but also other Members’ services.
Perl/CGI can only be enabled upon individual request, typically in the following cases:
Approval is always subject to technical and security review, and may be revoked if usage creates risk or excessive load.
This means that the Perl/CGI execution model does not guarantee the same directory-level isolation as modern isolated runtime environments.
In certain configurations, CGI scripts may access resources outside the user’s own directory, which:
This is one of the main reasons why Perl/CGI is not part of the default service set in xHOSTING.
Remote database access is not available by default because exposing a database service on the public network significantly increases the attack surface.
In a community-based infrastructure, the impact of security risks and abuse opportunities may affect not only a single account, but also the stability of the entire environment. Therefore, xHOSTING provides databases by default for internal (local) access only from within the hosting environment.
Typical risks of public database access include:
Since attackers commonly scan the internet en masse for database ports, public access by itself turns the service into a target.
Remote database access can be requested if the use is technically justified, for example:
Approval is always based on individual assessment, and may require, for example, providing the target IP address(es), strong authentication, and clarifying the purpose of use.
If remote database access is approved, xHOSTING’s goal is to keep that access narrowed and controlled. Typical restrictions include:
Access can be tightened or revoked at any time if it threatens the security or stability of the community infrastructure.
Restricting the SSH environment in the XBASIC package is a deliberate security and stability decision. In a community-based infrastructure, commands run via SSH can directly affect system resources and other Members’ services.
The goal of restricted SSH is to:
A restricted SSH environment means that a user logging in via SSH can work only within their own user directory.
In practice, this means:
/etc, /usr, /var);This approach keeps SSH access useful while preventing risk to the entire system.
Yes. The restricted SSH environment is well suited for typical development and maintenance tasks, such as:
SSH is therefore a fully usable tool for managing web projects, as long as the operations do not require system-level privileges.
In the restricted SSH environment, commands that would enable system-level changes or affect other users are not available. Typically blocked or unavailable:
apt, yum, dnf);systemctl, service);These restrictions ensure SSH access remains safe while everyday development tasks can still be carried out smoothly.
Excessive or unjustified resource usage includes any activity that places a disproportionate load on xHOSTING’s community infrastructure and may negatively affect other Members’ services.
This includes, in particular:
Assessment is always made with the community operation and the package boundaries in mind.
xHOSTING’s infrastructure monitors resource usage on multiple levels. The system uses automated monitoring and logging to detect patterns that deviate from normal, intended operation.
Monitoring may cover, among other things:
The goal is not constant surveillance of Members, but early detection of situations that threaten community stability.
If a Member’s resource usage causes sustained or repeated overload, xHOSTING may intervene to protect the community.
Possible measures may be gradual, for example:
The goal in every case is to restore community operation, not to punish.
Yes. xHOSTING aims to inform Members in advance about the issue whenever technically and practically possible.
In practice, this typically happens as:
Immediate intervention without prior warning occurs only if the load directly threatens the system or other Members’ operation.
The limit of 5 scheduled tasks means that in one xHOSTING account you can create up to five separate scheduled (cron) jobs. These jobs run automatically at defined intervals, for example to perform maintenance operations, scripts, or application tasks.
The purpose of the limit is not to reduce functionality, but to ensure the number of scheduled processes remains proportional to community resources.
Scheduled tasks are primarily meant for short-running, well-defined operations. Running long-running or continuously load-generating tasks from cron (such as large data processing or infinite loops) is not recommended.
If a task would legitimately run longer, it is advisable to optimize it, split it into smaller parts, or find a solution through individual coordination. Such loads can endanger the stability of the community infrastructure.
In community-based hosting, scheduled tasks are a sensitive area because they can load the system at the same time and at unpredictable moments.
The purpose of the limit is to:
Using scheduled tasks consciously is in every Member’s shared interest for reliable operation.
xHOSTING is not a classic, business-based hosting service, but a community system built on voluntary contributions. Accordingly, it does not offer a contractual service level (SLA), because an SLA would legally and technically imply business operation, guaranteed resources, and continuous availability.
The community model aims for sustainable, fair, and transparent operation—not the fulfillment of commercial commitments.
The lack of guaranteed uptime means that xHOSTING does not promise a specific availability percentage. Services generally run stably, but temporary outages may occur.
Operations aim for continuous service, but there is no legal or financial obligation to meet a defined uptime level.
A classic business hosting provider offers an SLA, guaranteed uptime, service credits/penalties, and customer support priority—in exchange for payment.
In contrast, xHOSTING:
Service outages may occur, among other things, in the following cases:
Handling such situations always serves to protect the community as a whole and ensure long-term operation.
The xHOSTING Control Panel (XCP) is xHOSTING’s unified control interface through which Members can manage settings related to their hosting and services.
Using XCP, you can manage, among others:
The control panel’s purpose is to provide independent, transparent, and secure administration without installing separate client software.
The technical foundation of the xHOSTING Control Panel (XCP) is provided by a modern, Linux-based hosting management system.
xHOSTING has built a multi-year professional relationship with the control panel’s developers, is the official language localizer of the system, and therefore has access to the full functionality of the commercial edition, receiving advance notice of all updates and changes before release. XCP uses a customized interface and permission model aligned with xHOSTING’s operation and rule set, providing a consistent xHOSTING experience for users.
The selection of the xHOSTING Control Panel (XCP) is the result of several professional and community considerations:
The system enables xHOSTING to operate a secure, sustainable, and flexible infrastructure without business-type constraints.
XCP differs from classic commercial control panels (such as cPanel or Plesk) in several key ways:
While cPanel and Plesk are designed for mass commercial customer hosting, XCP is tuned specifically to the needs of a closed, invite-only community.
Yes. The xHOSTING Control Panel (XCP) is fully usable from a web browser, without installing any additional software or client.
Most administrative tasks—such as file management, database administration, email settings, or backup management—are available directly through the browser.
For some advanced functions (e.g., an FTP client, an SSH connection, or an external email program), external tools can be used optionally, but they are not required to use XCP.
Logging in to the xHOSTING Control Panel (XCP) is done by entering a unique username and password on a web interface available over HTTPS.
The login credentials are created when membership is activated and are linked exclusively to the Member’s own account. The connection is always encrypted, so authentication data is not transmitted in plain form.
Yes. The xHOSTING Control Panel supports two-factor authentication (2FA), which provides an additional layer of protection for user accounts.
After enabling 2FA, logging in requires not only the password but also a time-based one-time code generated by an authenticator app (e.g., on a mobile phone).
Using two-factor authentication is strongly recommended for every Member.
In case of a forgotten password, the Member can use the password reset function available on the login page.
The system then sends a verification message to the contact email address associated with the account, through which a new password can be set.
For security reasons, the old password cannot be recovered—only a new password can be created.
Yes. The xHOSTING Control Panel logs successful and failed login attempts for security purposes.
Logging helps detect suspicious activity, protect accounts, and investigate potential abuse.
In case of repeated failed login attempts, the system may apply automatic protective measures (e.g., temporary restriction).
Adding a new domain in the xHOSTING Control Panel (XCP) is done through the menu section dedicated to domain management.
The Member can enter the domain name, select its type (primary domain, alias, or subdomain), then configure the related web, email, and DNS parameters. After activation, the system automatically creates the required directory structure and default settings.
Primary domain: an independent domain with its own web content and settings (e.g., mydomain.hu).
Alias domain: an additional domain pointing to an existing primary domain, serving the same content (e.g., mydomain.com → mydomain.hu).
Subdomain: a logical unit under the primary domain with a separate address (e.g., blog.mydomain.hu), which can be linked to a separate directory and even a separate application.
Within the XBASIC package, up to 3 domains and 3 subdomains can be used per domain.
Domain allocation is flexible, but the defined limits cannot be exceeded in order to balance community resource usage.
Yes. The Member is allowed to delete their own primary domains through the xHOSTING Control Panel.
Before deletion, the system shows a warning because the action is irreversible and the services associated with the domain will stop.
When a domain is deleted, the related web files, database links, email accounts, and other settings become inactive and may then be permanently removed after a technical delay.
It is the Member’s responsibility to back up data before deletion. xHOSTING does not assume liability for data loss resulting from deletion.
In the xHOSTING Control Panel (XCP), the most commonly used DNS record types can be fully managed.
These include in particular A, AAAA, CNAME, MX, TXT, SRV, and CAA records. Using these, you can configure web hosting, email routing, and various security and authentication mechanisms (e.g., SPF, DKIM, DMARC).
Yes. A Member may decide not to use xHOSTING-provided DNS management for a given domain, and instead configure their own or external DNS servers.
In that case, the domain’s nameservers (NS records) must be changed at the registrar. It is important to note that with this configuration, the Member is responsible for DNS operation and any related issues.
Manual DNS record changes are not recommended if the Member is not confident about the effects of the settings or lacks experience managing DNS configurations.
Incorrect entries may cause the website, email service, or other related functions to become temporarily or permanently unavailable. Extra care is required when modifying MX and TXT records.
DNS changes do not take effect instantly; they depend on so-called DNS propagation.
This can typically take anywhere from a few minutes up to 24–48 hours, depending on the record’s TTL value and the caching practices of internet service providers.
xHOSTING provides its own centrally operated nameservers for the community hosting service.
The current, official list of xHOSTING nameservers is always available in the xHOSTING Control Panel (XCP) and in the documentation. This is because the nameserver endpoints may change as the infrastructure evolves or undergoes technical restructuring, and the information published there is always authoritative.
Current nameservers:
After making changes, DNS delegation updates typically take from a few minutes up to 24–48 hours due to how the global DNS system works.
If your domain is registered with an external registrar or provider, you must change the nameservers there.
The steps are generally:
After the change, DNS delegation updates typically take from a few minutes up to 24–48 hours due to how the global DNS system works.
In this case, the domain’s DNS zone is not managed by xHOSTING, but by the external nameserver provider.
You must then configure the following DNS records correctly:
XCP shows, for each domain, the IP addresses and recommended record values required for proper web and email operation.
Important: if you use external DNS, the accuracy of the DNS configuration is entirely the domain owner’s responsibility. If records are incorrect or missing, the website or email service will not work properly.
The xHOSTING Control Panel (XCP) provides multiple file management options for Members.
Files can be managed via traditional FTP / SFTP connections, as well as via the browser-based file manager built into XCP. With these methods, you can upload, download, delete, rename files, change permissions, and manage directory structures.
Yes. XCP’s built-in file manager can be used entirely without FTP or an external client.
The file manager is accessible from a web browser and provides a practical solution for basic administration tasks (quick edits, editing configuration files, small uploads).
Files are accessible in the Member’s own isolated user environment.
Permission management is based on Linux filesystem permissions (owner, group, read/write/execute). The Member can access files only within their own directory and has no access to other Members’ data.
XCP itself does not provide a recycle bin or versioning feature to automatically restore deleted files.
Files can only be restored if the Member has a previously created backup. Therefore, regular personal backups are strongly recommended, including using the external backup destinations supported by XCP.
A new FTP user can be created in the xHOSTING Control Panel (XCP) independently, without administrator intervention.
The general steps are:
The created FTP user can be used immediately with the specified credentials.
Yes. XCP allows an FTP user to be limited to access only a specific directory.
Benefits of directory restriction:
The restriction can be set during user creation or later.
In the XBASIC package, up to 3 FTP users can be created.
This limit:
If an FTP user is no longer needed, it can be deleted and replaced with a new one.
Yes. In addition to FTP, xHOSTING also supports encrypted connections.
Available options:
Using SFTP requires SSH access to be enabled, while FTPS can be used without SSH access.
Using encrypted connections is strongly recommended, especially when connecting from a public or untrusted network.
The xHOSTING Control Panel (XCP) allows selecting the PHP version separately for each domain.
The setup process:
This makes it possible to run multiple websites under one hosting account with different PHP versions, depending on each application’s requirements.
XCP allows viewing—and within defined limits, modifying—several commonly used PHP directives.
Typically available settings include:
Editable values are constrained by the package’s technical and security limits, so they do not endanger the community infrastructure.
These PHP resource limits define the maximum memory and upload size that individual scripts can use.
These limits help to:
open_basedir is a PHP security restriction that defines which directories a PHP script is allowed to access.
The role of open_basedir:
This setting is a fundamental part of multi-user, community hosting security.
The disable_functions list contains PHP functions that are disabled for security reasons.
Typically disabled functions include:
The goal of disabling these is not to limit development, but to protect:
Creating a new database in the xHOSTING Control Panel (XCP) can be done in a few steps.
The creation process:
The created database can be used immediately for web applications or custom development.
In the xHOSTING environment, the most common database solutions optimized for web applications are available.
Supported database types:
These databases are compatible with most popular CMSs and web applications (e.g., WordPress, Joomla, custom projects).
The XBASIC package allows creating up to 3 databases.
This limit:
The number of databases is fixed within the package framework; special needs may be subject to individual review.
Yes, XCP provides a web-based database management interface that is accessible from a browser.
The web database manager allows:
Access is restricted by the permissions assigned to the given database, so only your own databases can be managed.
You can create a new email account in the xHOSTING Control Panel (XCP) via the email management interface.
General steps:
After creation, the account can be used immediately via webmail and in an email client.
In short: if you only want emails to be forwarded to another mailbox, an email address (alias or forwarding) is sufficient. If you need a separate login with its own storage space, you must create a real email account (mailbox).
Practical examples:
This helps you decide whether you need an actual mailbox or if simple forwarding is enough.
Yes. The catch-all feature is enabled in the XBASIC package.
Catch-all means:
Note:
Yes. Email forwarders can also be used in the XBASIC package.
What forwarding is useful for:
Recommendation:
Email passwords and (if available) quotas can be managed in XCP under the mailbox’s details.
Typically you will find it here:
Security minimum:
In XCP, Let’s Encrypt allows you to enable a free, automatically issued SSL/TLS certificate for your domains.
General flow:
Common prerequisites:
Yes, renewal of Let’s Encrypt certificates is basically automatic, as long as the domain can still be successfully validated at the time of renewal.
Typical reasons why renewal can fail:
If renewal is problematic, the process can typically be restarted / re-requested in XCP.
HSTS (HTTP Strict Transport Security) is a browser-side security rule that forces the browser to access the domain only over HTTPS.
Benefits:
When it is worth enabling:
Warning:
includeSubDomains is a security directive that extends HTTPS-only behavior not just to the main domain, but also to all existing subdomains.
Practical meaning:
Important note:
The preload directive indicates that the domain may be submitted to the HSTS preload list used by browsers.
In practice this means:
Important constraints:
Therefore, using preload is recommended only if you are sure that all subdomains will remain on HTTPS long-term.
This means that the selected security rules (for example, HTTPS enforcement, HSTS, includeSubDomains) apply not only to the main domain, but also to all existing subdomains.
Benefits:
Important to know:
Recommendation:
Yes. If you have your own SSL/TLS certificate (for example, EV/OV or one issued by an external CA), you can upload it in XCP.
You typically need:
Recommendation:
The xHOSTING Control Panel (XCP) allows Members to create and manage backups of their own data.
Core principles of backup management:
This approach provides more flexibility, but it also requires more conscious usage from the Member.
In the XBASIC package, multiple external backup destinations can be used, so Members can align their backup strategy with their own infrastructure.
Supported backup methods:
Exact configuration always depends on the technical requirements of the chosen destination.
Yes, XCP provides the option to set up automatic backup tasks.
Typical characteristics of automatic backups:
Important note:
Due to the community operating model, responsibility for regular data backups lies primarily with the Member.
In practice, this means:
Recommendation:
xHOSTING applies multi-layer, server-side spam filtering to protect email traffic.
The goal of the filtering is to block clearly unwanted messages before delivery, while ensuring that legitimate emails are delivered reliably. The system takes into account factors such as sender reputation, technical authentication checks, and content characteristics.
xHOSTING’s server-side spam filtering uses a multi-layer protection model.
The system is based on statistical analysis, adaptive (machine-learning-based) scoring, and authentication checks (SPF, DKIM, DMARC). This makes it possible to filter out a large portion of unsolicited emails before delivery.
Machine-learning-based spam filtering means that the system analyzes email characteristics using statistical methods.
The filter evaluates factors such as message content, header data, sending patterns, and previous observations. Based on these signals, it continuously refines its scoring, allowing it to distinguish legitimate messages from spam more effectively over time.
Yes. The spam filter operates in an adaptive manner.
The system continuously improves detection based on patterns found in incoming messages. This means that common spam types are identified with increasing accuracy over time, while the likelihood of false positives is reduced.
Emails classified as spam are typically not deleted immediately.
The system marks such messages as spam or handles them in a separated manner, allowing them to be reviewed if necessary. The exact behavior also depends on the email account settings and client-side filtering rules.
Yes, in rare cases a so-called “false positive” may occur, where a legitimate email is classified as spam.
This typically happens when the sender’s domain is misconfigured, authentication records are missing, or unusual content patterns are detected. In such cases, it is recommended to review the sender’s technical configuration or whitelist the sender in the email client.
Yes. The amount of spam can be significantly reduced with conscious configuration and usage.
Recommended steps:
The combination of server-side protection and user awareness provides the best results.
No. A completely spam-free email service does not exist.
The goal of xHOSTING is to filter out the vast majority of unsolicited messages while reliably delivering legitimate emails. Spam protection is a continuous balance between strict filtering and safe message delivery.
No.
The domain xhosting.hu is not affiliated with any other similarly named foreign or domestic hosting provider (e.g., x10hosting).