If you host a Java application on a managed hosting platform with Plesk, creating a dedicated FTP account is one of the simplest ways to give a developer controlled access to your Tomcat project files. A separate FTP user lets you upload WAR files, JSP pages, configuration files, static assets, and deployment resources without sharing the main control panel login.
For Tomcat hosting, the most common approach is to create an FTP account that points to the application’s deploy path or to the website root used by your Java project. This keeps file permissions clearer, makes deployment easier, and helps you limit access to only the folders that matter for the app.
Why create a separate FTP account for a Tomcat project
When you manage a Tomcat project through Plesk or a similar hosting control panel, using a dedicated FTP account is usually better than sharing the main account credentials. It gives you more control over who can change application files and where they can upload content.
- Safer access control: Give developers access only to the application directory, not the whole hosting account.
- Cleaner project management: Keep Tomcat files separate from other website files, logs, and mail data.
- Easier deployment: Upload WAR, JSP, class files, resources, or static assets directly to the correct path.
- Better accountability: Each FTP user can be created for a specific person or purpose.
- Useful for managed Java hosting: Works well with private JVM and Tomcat setups inside a shared hosting account.
If your hosting plan includes a Java hosting solution such as My App Server, FTP access is often part of the normal file-management workflow. You can use FTP to move application packages into the right deploy path and then manage the runtime separately through Plesk.
Before you create the FTP account
Before adding a new FTP user, identify the exact folder that your Tomcat project uses. In a typical Plesk-based setup, that may be one of the following:
- The website root for the domain
- A dedicated application folder used by the Tomcat service
- A deploy directory where WAR files are uploaded
- A content folder for JSP, static assets, or support files
If your Tomcat deployment uses a private JVM or a custom app server setup, make sure you know whether the application reads files from the web root, a separate deploy path, or an internal directory used by the Tomcat instance. Uploading to the wrong folder can prevent the app from starting correctly or make files unavailable to the servlet container.
It is also a good idea to confirm:
- The hosting account has FTP access enabled
- You know the correct username and password policy
- The target directory already exists
- The user should have read/write access only where needed
How to create an FTP account in Plesk
The exact labels may vary slightly depending on the hosting platform, but the workflow in Plesk is usually straightforward. If your hosting provider uses a custom Java extension such as My App Server, the FTP account is still typically created in the main hosting or subscription area, then mapped to the relevant project folder.
Step 1: Sign in to Plesk
Log in to your hosting control panel and open the subscription or domain that contains the Tomcat project. If you manage multiple sites, make sure you are working with the correct domain or application container.
Step 2: Open the FTP access section
Look for a section named FTP Access, FTP Accounts, or Web Hosting Access. In some installations, FTP users are managed from the domain overview, while in others they are available under hosting settings.
Step 3: Add a new FTP user
Select the option to create a new FTP account. Fill in the required fields, which usually include:
- FTP username: Use a clear name, such as the developer name or project name
- Password: Choose a strong password or generate one automatically
- Home directory: Point the account to the Tomcat project folder or deploy path
For example, if the application files are stored in a folder such as httpdocs/app or a custom deploy directory used by the Java service, assign that location as the FTP user’s home directory. This limits access to only the project files.
Step 4: Set the correct directory permissions
Make sure the FTP account has sufficient permissions to upload and edit files in the target directory. In most hosted environments, the control panel handles the permissions automatically, but it is still important to verify that the account can:
- Upload WAR files
- Replace JSP or HTML files
- Update configuration files
- Create folders if needed
- Read existing application resources
If the project uses a Tomcat deploy path that is watched by the application service, file permissions should support the upload process without making the folder writable more broadly than necessary.
Step 5: Save the account
After you save the FTP user, Plesk will display the account details or place it in the FTP user list. Use those credentials in an FTP client such as FileZilla or another secure file-transfer tool approved by your hosting environment.
Choosing the right folder for a Tomcat FTP account
The most important decision is not the FTP username itself, but the folder the account can access. For Tomcat hosting, the chosen directory should match the way your application is deployed and updated.
Common folder options
- Application root: Best when files are loaded directly from the website root or a mapped document root
- WAR deploy folder: Best when you upload a WAR package for Tomcat to unpack or redeploy
- Source or content folder: Best for JSP, static resources, and supporting web files
- Custom app directory: Best for setups with a separate Java service path in Plesk
If you are using a Plesk extension like My App Server, the deploy path may be different from a standard PHP website. In that case, follow the app server path shown in the service settings rather than assuming the default web root. This is especially important when a private Tomcat instance is installed for one project inside a shared account.
What not to do
- Do not point the FTP user to the entire hosting account unless it is absolutely required
- Do not use the same FTP account for multiple unrelated projects
- Do not upload Tomcat application files into a generic public folder if the service expects a separate deploy path
- Do not give write access to folders that should remain read-only
How FTP works with Tomcat, JSP, and WAR deployments
Tomcat hosting is often used for JSP hosting, servlet hosting, and small to medium Java applications. In these setups, FTP is mainly used to move files into the project directory so the application can be deployed or updated.
Typical file types you may upload through FTP include:
- .war application packages
- .jsp pages
- .class or compiled resources, depending on the project structure
- .properties or configuration files
- .xml deployment descriptors
- images, CSS, JavaScript, and other static assets
In some hosting environments, uploading a new WAR file to the deploy path may trigger a redeployment or refresh of the Tomcat application. In others, you may need to restart the service from Plesk or use the app server controls to apply the changes.
If your hosting account includes a service control interface for the Java runtime, check whether the new files should be uploaded first and the service restarted second. This order helps avoid partial deployments or file-locking issues.
FTP setup recommendations for Java hosting accounts
When you create an FTP account for a Tomcat project, a few practical settings can make daily work easier and safer.
Use a descriptive username
Choose a username that identifies the project or the person using it. Examples include project-specific names or role-based names such as tomcat-dev or app-deploy. This helps when several users work on the same hosted application.
Limit access to one application folder
Whenever possible, map the account to the exact directory used by the Tomcat application. This reduces the risk of accidental changes to other files on the hosting account.
Use strong credentials
FTP passwords should be unique and strong. If your hosting platform supports secure transfer protocols, use them instead of plain FTP whenever possible. File transfers for application code and configuration files should be protected in transit.
Separate deployment access from admin access
If one person manages runtime settings in Plesk and another uploads the code, keep those responsibilities separate. The person who deploys the WAR file does not necessarily need access to service control, Java version selection, or other hosting settings.
Review access after changes
If the deploy path changes, or if the project is moved to another Tomcat instance, update the FTP account home directory accordingly. Old paths can cause confusion and failed uploads.
Troubleshooting common FTP issues
FTP problems are often caused by folder mapping, permissions, or incorrect login details. For Tomcat projects, these issues can also appear when the deploy path does not match the app server configuration.
Cannot log in to FTP
Check the username and password first. If the hosting panel allows it, reset the password and test again. Also confirm that the account has not been deleted or disabled.
Can connect, but cannot upload files
This usually means the user does not have write permission for the selected folder. Review the home directory and make sure it points to a writable application path.
Files upload, but the Tomcat app does not change
The application may be deployed from a different location than the one you updated. Verify the Tomcat deploy path, then restart or refresh the service if needed. In a managed hosting setup, the app server may need to reload the WAR package before the changes become visible.
Uploaded files disappear after redeploy
If Tomcat unpacks a WAR into a managed directory, manual changes in the unpacked folder may be overwritten on the next deployment. In that case, upload the source package or update the persistent build files instead of editing the exploded directory directly.
Site shows old content after file upload
Clear any application cache if your Java app uses one. Also check whether browser caching, reverse proxy caching, or Tomcat session behavior is hiding the updated file. If the platform provides a service control option, restart the app carefully after deployment.
Best practices for managed Tomcat hosting
On a managed hosting platform, the goal is usually to keep deployment simple while still preserving enough control for Java application maintenance. FTP should support that workflow, not replace it.
- Use FTP for file transfer, not for broad server administration
- Keep Tomcat application files in a dedicated folder structure
- Use the hosting control panel for service control and Java version management
- Upload only the files that need to change
- Document which FTP user belongs to which project or developer
If your account includes a private JVM or custom app server provided through Plesk, the FTP account should be aligned with the application path configured in that service. This keeps deployment predictable and reduces errors during updates.
Example workflow for a Tomcat deployment
Here is a practical example of how an FTP account is commonly used in a Tomcat hosting environment:
- A developer receives an FTP username with access to the application deploy directory only.
- The developer uploads a new WAR file or updated JSP resources.
- The files are placed in the correct folder used by the Tomcat instance.
- The hosting panel or app server service is checked to confirm whether a restart is needed.
- The application is tested in the browser after the deployment completes.
This workflow is simple, but it works well for Java hosting, servlet applications, and small custom web apps where a separate Tomcat instance is managed through the control panel.
FAQ
Can I use one FTP account for several Tomcat projects?
You can, but it is usually better to create separate FTP accounts for separate projects. That makes permissions easier to manage and reduces the risk of uploading files into the wrong directory.
Should the FTP account point to the Tomcat web root or the deploy folder?
It should point to the folder that matches your deployment model. If your app is deployed from a WAR directory, use the deploy path. If your project is managed directly from a web root or application content folder, use that location instead.
Can I upload a WAR file through FTP?
Yes. In many Tomcat hosting setups, FTP is the normal way to upload WAR files to the deploy path. After the upload, you may need to restart the service or wait for Tomcat to redeploy the application.
Do I need shell access to create an FTP account?
No. In most hosting platforms, FTP accounts are created directly in Plesk or in the hosting control panel. Shell access is not required for basic file transfer users.
What if my Java app uses a custom app server path?
Then the FTP account should be created for that exact custom path. Do not assume the default website folder is correct. Check the app server settings to confirm the deploy directory before saving the account.
Is FTP enough for managing a Tomcat project?
FTP is enough for file uploads and basic updates, but the full Tomcat service still needs to be managed from the control panel. For example, Java version selection, service start and stop, and application configuration should be handled in Plesk or the hosting interface.
Conclusion
Creating a dedicated FTP account for a Tomcat project is a practical way to manage deployments in a Plesk-based hosting environment. It gives developers controlled access to the application files, supports cleaner file organization, and helps match the FTP user to the correct deploy path.
For Java hosting setups such as My App Server, the key is to connect the FTP account to the right application directory and keep file access aligned with the Tomcat service configuration. When you do that, uploading WAR files, updating JSP pages, and managing project assets becomes much easier and less error-prone.
If you are working with a managed Tomcat hosting plan, always verify the deploy path, permissions, and service behavior before publishing changes. That small check can save time and prevent deployment issues later.