Keeping Tomcat deployment files organised is one of the easiest ways to avoid broken releases, confusing rollbacks, and accidental file overwrites on a hosting account. When you manage Java hosting through Plesk and a private Tomcat instance, a clear file structure helps you separate source files, build output, deploy packages, logs, and configuration backups. That becomes especially useful when you deploy WAR files, JSP applications, or servlet-based projects from a shared hosting environment where the control panel is part of your day-to-day workflow.
On a managed hosting platform with a Tomcat service available through Plesk, the best approach is to treat deployment files as a working system rather than a single upload folder. Keep your application package, extracted web files, versioned backups, and temporary build artefacts in different locations. That makes updates safer, helps with troubleshooting, and reduces the chance of deploying the wrong archive to the wrong path.
Why file organisation matters for Tomcat hosting
Tomcat deployments are more reliable when each file has a clear purpose. A tidy structure helps you answer questions quickly: which version is live, where the WAR file came from, which files were uploaded manually, and what should be kept after a rollback. This is useful for UK hosting customers who want practical control over Java and Tomcat without needing a full enterprise application server setup.
Good file organisation also supports common hosting tasks in Plesk:
- separating application source code from deployment output;
- keeping Tomcat WAR files and exploded application directories easy to identify;
- storing Java build artefacts away from public web roots;
- making FTP uploads less error-prone;
- simplifying support requests when you need to review deploy paths or file permissions.
With My App Server, you can manage a private JVM and Tomcat instance inside your hosting account, which makes clean file handling even more important. A small, organised structure is usually better than a large shared folder full of mixed files.
Recommended folder layout for Tomcat deployment files
A simple and consistent folder structure is usually the best choice. Whether you deploy a WAR file manually, upload application assets through FTP, or use a Plesk file manager, try to keep the same pattern for every project.
Suggested structure
- /source/ for project source code, documentation, and build scripts;
- /build/ for compiled output, generated WAR files, and packaging steps;
- /deploy/ for files prepared for upload or release;
- /backup/ for previous versions of WARs, configuration copies, and rollback archives;
- /logs/ for exported logs if you need to keep them outside the Tomcat log location;
- /tmp/ for temporary files during testing or migration.
If your hosting account uses separate application paths for Tomcat, keep the live deployment directory distinct from these working folders. The live app path should contain only what Tomcat needs to run, while everything else should stay in a private project area.
Example project layout
A practical example might look like this:
- /home/username/appname/source/ - Java source, JSP templates, static assets;
- /home/username/appname/build/appname.war - packaged deployment file;
- /home/username/appname/backup/appname-2026-04-01.war - previous release;
- /home/username/appname/deploy/ - files staged for upload;
- /home/username/tomcat/webapps/appname/ - live application directory, if your setup uses an exploded deployment.
Use names that make the role of each folder obvious. Avoid vague labels like new, test2, or final, because they become hard to maintain over time.
How to organise Tomcat WAR files and exploded deployments
Most Tomcat hosting setups use either a WAR file deployment or an exploded application directory. Both can work well, but each needs a different level of discipline.
WAR file deployments
If you deploy a WAR file, keep the original build artefact, the uploaded file, and any archived older version separate. A clean process might be:
- build the WAR in your local or staging environment;
- rename it clearly with the application name and release date or version;
- store a copy in a backup folder before upload;
- upload the selected WAR file to the Tomcat deploy path;
- verify the deployed application and remove any obsolete temporary files.
For example, shopapp-1.4.2.war is easier to manage than app_new_latest_final.war. Versioned names make rollbacks easier and reduce confusion when several releases exist at once.
Exploded deployments
Some applications are deployed as an extracted directory rather than a single WAR. In this case, keep the extracted live folder as clean as possible. Only application files that must be served or executed should be inside the deployment path. Build scripts, source repositories, and backup archives should stay elsewhere.
If you update an exploded app manually, do not mix old and new files in the same directory without checking. A common problem is leaving an outdated JSP, class, or static asset in place after a partial upload. To avoid this, compare file timestamps, remove obsolete items carefully, and prefer a full replacement where possible.
Best practices for FTP uploads and Plesk file management
When you use FTP or Plesk file manager to move deployment files, consistency matters more than speed. Uploading files into the wrong folder is one of the most common causes of Tomcat deployment issues.
Use a staging folder before going live
Instead of uploading directly into the live application path, create a staging folder first. Place the new WAR or extracted files there, confirm they are complete, and then move them to the deploy location when you are ready. This reduces the chance of partial uploads causing downtime or broken pages.
Keep file names predictable
Choose a naming convention and use it every time. Good examples include:
- application-name-1.0.war
- application-name-2026-04-22.war
- application-name-prod.war
- application-name-test.war
Pick one pattern and stay with it. Mixing release numbers, dates, and informal names can make it harder to identify the correct file during an urgent update.
Avoid public web root clutter
Your public web root should not be used as a general storage area for old packages, notes, database dumps, or temporary uploads. Keep application deployment files in the exact path required by your Tomcat setup and store everything else outside the public-facing directory. That improves security and makes cleanup much easier.
Check permissions after upload
Even when the file structure is correct, wrong permissions can stop Tomcat from reading or updating files. After an FTP upload or file manager change, verify that the application files have suitable ownership and access rights for your hosting environment. If your managed hosting platform provides a control panel service, use it to check the deployed application state before assuming the upload failed.
How My App Server helps with Tomcat file organisation
With ITA’s My App Server extension in Plesk, the hosting account can run a private Tomcat instance and a dedicated JVM. That gives you more control over where application files live and how they are deployed, while still keeping the setup manageable inside a shared hosting account.
This is useful for Java hosting projects that need:
- a separate runtime for a single application or a small group of apps;
- control over Java version selection;
- simple management through Plesk instead of server-level administration;
- straightforward deploy paths for WAR, JSP, and servlet applications;
- clear service control without needing a full enterprise stack.
Because the service is designed for practical Java and Tomcat hosting, it is a good idea to keep your files easy to deploy and easy to replace. That means versioned archives, tidy directories, and no unnecessary files inside the live application path.
What to keep in the live deploy path and what to keep elsewhere
A good rule is simple: if Tomcat must read it to run the application, keep it in the deploy path; if not, store it elsewhere.
Keep in the live path
- WAR file or exploded application content;
- JSP pages and servlet-related resources;
- static assets used by the application;
- configuration files required by the deployed app, if your setup expects them there;
- runtime directories that the application specifically needs.
Keep outside the live path
- source repositories;
- IDE project files;
- old release archives;
- build scripts and packaging tools;
- database exports and large temporary files;
- notes, documentation, and test dumps.
This separation helps prevent accidental exposure of sensitive files and makes it easier to understand what is actually being served.
Version control and backup habits for deployment files
Even on a managed hosting platform, basic versioning and backup habits are essential. If a release goes wrong, your rollback should be quick and predictable.
Use release versions or dates
Store each deployment artefact with a clear version number or date. For example, keep:
- invoiceapp-2.1.0.war
- invoiceapp-2.1.0-backup.war
- invoiceapp-2026-04-22.zip
That way, you can identify the exact file used in production and restore it if necessary.
Keep a rollback copy
Before replacing the live application, save the current WAR or directory state in a backup folder. If you need to revert because of a bug, missing resource, or deployment failure, the previous version is ready to restore.
Do not rely on one copy only
Keep at least one separate backup outside the active Tomcat path. A deployment folder should not be the only place where a release exists. If the live directory is cleaned during an update, the backup copy protects you from data loss.
Common mistakes when organising Tomcat files
Many deployment problems are caused not by Tomcat itself, but by file handling mistakes. These are the most common ones to avoid:
- Uploading to the wrong directory: the application appears missing because files were placed outside the deploy path.
- Mixing source and live files: development-only files end up in production.
- Leaving old files behind: outdated JSP or class files interfere with the new release.
- Using unclear file names: nobody can tell which archive is current.
- Skipping backups: rollback becomes slow or impossible.
- Storing temporary files in the live path: clutter makes troubleshooting harder.
- Ignoring permissions: uploaded files exist, but Tomcat cannot read them properly.
These issues are easy to prevent if you follow one folder pattern and keep deployment tasks consistent.
Practical deployment workflow for Tomcat on hosting
A repeatable workflow reduces errors. The following approach works well for small and medium Java applications hosted through Plesk:
- Prepare the release locally and confirm it builds correctly.
- Create a versioned WAR or packaged directory.
- Copy the current live release into a backup folder.
- Upload the new package to a staging directory first.
- Verify file size, name, and timestamp.
- Move or deploy the package to the Tomcat application path.
- Check the application in the browser and review logs if needed.
- Remove temporary staging files once the release is confirmed.
This workflow is especially useful when you manage the application from a hosting control panel and want a clear separation between preparation and live deployment.
File organisation tips for JSP and servlet applications
JSP and servlet applications can become messy quickly if static files, compiled classes, and configuration files are mixed together. Keep the following in mind:
- store JSP pages in the app’s web content structure, not in build folders;
- do not leave local IDE project metadata on the server;
- keep library files only if the application actually needs them;
- remove old class files when replacing a compiled application directory;
- separate environment-specific configuration from general web assets.
If your Tomcat deployment uses a private JVM through My App Server, this clean separation helps the runtime start faster and reduces confusion when troubleshooting.
When to ask support for help
If the file structure is correct but your application still does not deploy as expected, the issue may be related to the configured deploy path, service state, or file permissions. In a managed hosting environment, support can often help you confirm the expected location for WAR files, verify service status, or check whether the Tomcat instance is reading the intended directory.
Useful situations to ask for help include:
- you are unsure which folder is the active deploy path;
- the application works locally but not after upload;
- Tomcat starts, but the app is not visible;
- an old version keeps loading after deployment;
- you need help understanding whether the app should be deployed as WAR or exploded files.
FAQ
Should I keep source code on the hosting account?
Only if you need it for deployment, maintenance, or rollback. In most cases, keep source code in a private folder outside the live Tomcat path and upload only the files required for the application to run.
Is it better to deploy a WAR file or an exploded directory?
For most hosted Tomcat applications, a WAR file is easier to manage because it is cleaner, versioned, and simpler to upload. An exploded directory can be useful for some workflows, but it needs more careful file handling.
Can I store multiple versions of the same application in one account?
Yes, and it is often a good idea. Keep each version in a separate backup or archive folder so you can roll back quickly if the latest release has a problem.
What is the safest way to update a Tomcat application?
Back up the current release, upload the new package to a staging folder, verify it, and then replace the live deployment path. Avoid copying over files blindly without checking what changed.
Why does Tomcat sometimes keep serving old files?
This can happen if an old exploded directory still exists, a cached resource is being used, or the new package was uploaded to the wrong path. Check the live deploy directory, remove obsolete files carefully, and confirm the application restart or reload if your setup requires it.
Where should logs be kept?
Tomcat will usually write logs to its configured log location. If you export logs manually, keep copies in a separate folder outside the live application path so they do not clutter the deployment directory.
Conclusion
Keeping Tomcat deployment files organised is mostly about consistency: clear folder names, versioned packages, separate backup copies, and a clean live deploy path. In a Plesk-based hosting environment with My App Server, that approach makes Java hosting easier to manage, whether you are deploying a WAR file, updating JSP pages, or maintaining a private JVM for a small application.
If you follow a simple structure and keep deployment artefacts away from source files and temporary content, your Tomcat hosting becomes easier to support, safer to update, and much simpler to roll back when needed.