TNS Panel
Get started

Client guide

The client interface is at https://<host>:2083. Admins and resellers see the same screens for the accounts they manage (without impersonating) in their own interface. What a client can do depends on their plan, and on the permissions of the sign-in being used if it is a sub-user.

Plans can cap: sites, subdomains, parked domains, mail domains, mailboxes, databases, FTP accounts, zones, containers, cron jobs, emails per hour, disk, inodes, transfer, and CPU/RAM/IO/processes. When a cap is reached the panel says so with a specific message (see FAQ).

Signing in, password and second factor

  • Clients can use a second factor (TOTP). It is optional for clients and mandatory for admins and resellers.
  • Forgot password on the sign-in page emails a one-time link (valid for one hour) to the recovery address stored on the account. The answer is identical whether or not the account exists. Changing that recovery address requires your current password.
  • Changing your password or second factor closes all your sessions.

Sites, domains and aliases

A client has a UNIX user and a home directory; each site is a domain with a document root. The first site's root is /home/<client>/public_html; additional sites use /home/<client>/<domain>/public_html (the same convention as CWP and DirectAdmin).

  • Aliases are extra names served by the same site.
  • Parked domains are extra names added to a site; they are covered by the site's wildcard certificate and never request a certificate of their own.
  • Subdomains are created as sites.
  • Redirects, error pages, index listing, upload size, hotlink protection, IP blocking, HTTP→HTTPS and HSTS, and password-protected directories are chosen from fixed options on Websites → site → Options, not by editing server configuration. HTTPS redirect and HSTS come on by default (your plan sets the default; you can change it per site). HSTS is only sent on sites with a valid certificate. Password-protected directories use SHA-512 hashes, stored outside your web root.
  • .htaccess is supported with full overrides on Apache.
  • Custom server directives (raw Apache/nginx text) are an admin-granted permission, off by default, because they are equivalent to root on the node.
  • A new site cannot use a name that belongs to another client's domain, zone or subdomain tree, or reserved names of the node.

Certificates

Certificates are issued and renewed automatically by Let's Encrypt. If the DNS zone for the domain is served by this node, one wildcard certificate (*.example.com and example.com) covers the site and any subdomain you add later. Otherwise each name gets a normal certificate over HTTP-01, so the domain must already point at the node.

  • Issuing on demand is rate-limited per domain to protect the shared Let's Encrypt quota.
  • Upload your own certificate (Websites → site → Own certificate): certificate, key and chain; the key must match.
  • CSR generator: create a key and signing request for a commercial certificate; the private key is stored encrypted so it can be installed when the certificate arrives.

DNS

If the node serves your DNS, DNS lets you manage zones and records (A, AAAA, CNAME, MX, TXT, SRV, NS, CAA). Records are validated; a TXT longer than 255 bytes (such as a DKIM key) is split correctly. Targets without a trailing dot are rejected, because they silently turn into name.zone.zone.

  • New zones come from a template. Resellers and the admin can define their own zone templates (name servers, MX, TXT, CNAME).
  • DNSSEC: turn it on per zone; the panel shows the DS record to give your registrar.
  • PTR (reverse DNS): the panel shows what the PTR should be. It can only publish it if your IP provider delegates the reverse zone to this node; otherwise set it in the provider's panel.
  • A zone name that overlaps another client's tree (parent or subdomain) is rejected.
  • Mail records (SPF, DKIM, DMARC with p=none) are published automatically when you add a mail domain, only if this node serves the zone.

If your DNS is elsewhere, the panel gives you the records to add.

Email

Email → Mail domains adds a domain to the node's mail system. You can only add a domain that already exists in your account as a zone or a site. After that:

  • Mailboxes with a quota. Passwords are hashed; the panel never stores them in clear.
  • Aliases (forwards) and a catch-all (default is reject).
  • Webmail (Roundcube) at https://webmail.<domain>: users sign in with their address and mailbox password. No panel account is needed.
  • Autoconfiguration for Thunderbird and Outlook/Apple Mail is published by default for each domain.
  • Filters, auto-responder and block/allow lists (Email → Filters): chosen from fixed options; the panel writes the Sieve script. Forwarding in filters is capped per mailbox. The auto-responder always limits repeat replies.
  • Discussion lists: if the admin enabled a list engine, you can create lists from Email → Lists.
  • Delivery tracking (Email → Tracking) shows what happened to a message (delivered, bounced, deferred) filtered to your own domains.
  • DKIM: signing is automatic. To rotate a key, use the three-step flow: Prepare (new key, new DNS record, still signing with the old one), wait for DNS to propagate, Confirm (switch signing), then Retire (delete the old record).
  • Sending from websites: PHP's mail() works, and is limited by your plan's emails per hour. Authenticated sending on port 587 counts against the same hourly limit. If a message cannot be attributed to an account it is rejected with a temporary error, and the sender retries. Authenticated users can only send as their own address.
  • DKIM signing applies to authenticated submission (ports 587/465), signed with the domain of the envelope sender. Mail from PHP's mail() is not DKIM-signed; use authenticated SMTP from your application when you need signed mail.

Remote mailbox migration from another IMAP server (Email → Mailbox → Import) is available to admins; the target mailbox must be new and empty.

Databases

Databases creates MariaDB or PostgreSQL databases and users. Names are <client>_<name>; the prefix is added for you.

  • Create a database, create a database user, and grant the user access to the database. A user can be granted several databases.
  • phpMyAdmin / phpPgAdmin open from the panel with one click, already signed in. They are only reachable through the panel, never on a public URL.
  • Remote access (Databases → Remote access): the admin chooses the node policy: closed (default), open to all, or only to IP addresses that you register. With the third policy you add your own addresses; MySQL grants are then limited to those hosts as well as the firewall.
  • Database users have no global privileges and can never grant access to others.
  • Support staff can open a database with a temporary identity that expires after 30 minutes; your real password is never shown to them.

FTP and SFTP

FTP creates virtual accounts named <client>_<name>, each rooted in a subdirectory of your home.

  • FTP requires TLS (FTPS, explicit); plain FTP is off. Passive ports 30000-30100.
  • Virtual FTP accounts are not UNIX users; files they upload belong to you and are readable by the web server.
  • SFTP with your account's UNIX user works for every active account. SFTP is the access every account has by default.
  • SSH keys (Access → SSH keys): add a public key for your account. A key does not grant access by itself: what the account may do is decided by its shell setting (SFTP-only or SFTP plus shell). The panel only manages the keys it added.
  • Shell access, if your provider enabled it, runs inside a jail that shows only your files, your processes and your tmp. SSH port forwarding and tunneling are off.

File manager

Access → File manager lists, uploads (up to 1 GiB per file, streamed), downloads, creates folders, renames, deletes, changes permissions, compresses and extracts .zip. It runs inside your home only, as your user, and is limited by your disk quota. Setuid/setgid/sticky bits cannot be set. Large listings are paginated.

Terminal

Access → Terminal opens a console in your browser (WebSocket) inside the same jail as SSH. It is only available if your account has shell access enabled by your provider; otherwise the page tells you to ask. At most 3 terminals per account; idle terminals close after 30 minutes; sub-users cannot open it. Suspending the account closes open terminals.

Cron jobs

Cron jobs: schedule a command with a five-field schedule or @hourly, @daily, @weekly, @monthly, @yearly. @reboot is not allowed. Jobs run as your user, in the same jail as SSH, and inside your account's CPU/RAM limits. % in a command is handled for you. You can disable a job without deleting it. If a job is not running, check the plan's cron-job cap and that cron is up (the admin sees it in Services).

One-click applications

Websites → Applications installs from a closed, version-pinned catalog into a site:

WordPress, Drupal, Joomla, Nextcloud, Moodle, PrestaShop, OpenCart, phpBB, osTicket and Kanboard.

  • The panel creates the database and user and writes the configuration. For WordPress, Drupal, Joomla and others that finish setup in the browser, you complete the final step on the site.
  • Some applications need PHP extensions or a PHP version the node may not have; in that case the panel refuses before downloading and tells you which one is missing (HTTP 409). For example PrestaShop only supports up to PHP 8.1.
  • Installation is checked by looking at the result on disk, not by trusting the installer's exit code.
  • Matomo, Dolibarr, Piwigo and Odoo are not offered.

WordPress tools (Websites → WordPress): detect installs, check for known vulnerable plugins/themes, update core or a component, maintenance mode, and clone a site with its database.

Git deployment and staging

Websites → Git deploys a site from a repository.

  • HTTPS URLs only. For a private repository, add an access token (stored encrypted). SSH and git:// URLs are not accepted.
  • The panel clones into a work directory outside your web root, then publishes to the site's document root without the .git directory. Submodules are not followed.
  • Staging: creates staging.<domain> as a real site, marked noindex in all three web servers. Publish copies the staging files onto the live site, deleting live files that no longer exist in staging. It does not touch the database, and creating a staging site does not clone it: until you point the staging configuration at another database it writes to the same one as production.

Containers and app presets

Websites → Containers (needs a License) runs an application as a rootless Podman container owned by your account, with its own subdomain and certificate. You choose either:

  • a preset: ASP.NET Core, Node.js, Python, Ruby or Java, with the official image and the correct port and volume pre-filled (the page tells you where to put your code and which port to listen on; apps must listen on 0.0.0.0); or
  • an image you name.

Each container gets a loopback-only port from 33000 upward; visitors reach it through your subdomain on 443. Containers count against your plan and your disk quota and are stopped when the account is suspended. They come back after a node reboot.

A Kubernetes manifest (Pod/Deployment YAML) can be deployed through the API (POST /api/contenedores/kube) and runs with podman kube play; host ports, host networking and privileged containers are rejected. There is no screen for this yet (Coming soon).

Sub-users

Access → Sub-users lets you create extra sign-ins for your account (an employee, an agency) and tick the areas each may use: sites, DNS, email, databases, FTP, files, backups, storage, cron, containers, certificates, statistics. Everyone can see their own usage and change their own password. Sub-users cannot create other sub-users, change their own permissions, open the terminal, or do anything that belongs to the admin or reseller. Removing a permission takes effect immediately by closing that sub-user's sessions.

Backups and restore

The node backs up every account, whether or not you bought a backup plan. What you can see and restore yourself depends on your backup plan (days of history you can reach; 0 is no limit). Without a plan you cannot browse or trigger backups, and the page says so; ask your provider.

  • Your backup includes your home directory and your databases (dumped consistently) and the database identities (as hashes, so passwords survive a restore).
  • Back up now: allowed, with a wait of one hour between manual runs.
  • Restore by item (Backups → Restore): browse a snapshot, choose files/folders or one database, and restore next to the original (default; nothing is overwritten, files appear in a folder in your home) or over the original. A restore is refused if it would not fit in your disk quota, and an item that is not in the snapshot is an error, not a success. Databases are restored whole.
  • Download: build a .tar.gz of a snapshot to download. The panel prepares it in the background and it expires; one at a time per account.
  • Your own backup destination (Backups → My destination): choose where your copies also go: SFTP, S3 or B2 directly; FTPS and consumer cloud storage (Google Drive, OneDrive, Dropbox, Box) through rclone. This is a separate repository, so you lose deduplication against other clients. Destinations pointing at loopback, private networks, link-local or cloud-metadata addresses are refused. For SFTP the panel generates a key for the destination and shows you its public half; you add it on your server and confirm the server fingerprint before the first copy. Cloud destinations use tokens that can expire or be revoked, and the backup silently stops until you refresh it: the advisor reports destinations that have not run.

External storage (FTPS/SFTP/S3 mounted in your home)

Backups → Storage: a remote storage your provider connected (SFTP, S3 or FTPS) is mounted at ~/storage. It looks like any folder, appears over FTP and in the file manager, and is not included in your home backups or malware scans. The quota is the remote provider's, not the node's. SFTP storage needs its server fingerprint confirmed before it mounts. If the remote is unreachable, the mount is simply absent.

Coming soon: serving that storage back to you as an S3 endpoint with sub-users.

Statistics

Statistics shows visitors, pages, referrers and traffic per site from your own access logs, using GoAccess; the report is processed once per log rotation and old logs can be rotated or deleted without losing history. The report opens in its own tab for security reasons. Monthly transfer against your plan is shown on Usage and the overage policy of your plan applies.

Logs and usage

  • Logs: view the last part of the access, error, PHP and slow-query log for each site, or download it. Viewing is audited because access logs contain visitors' IP addresses.
  • Usage / Consumption: disk, inodes, transfer and CPU/RAM/IO history for your account.
  • Malware scan: scans your own files and reports; it never deletes. Reports show an indicator, not the file contents.