Before deploying a Tomcat application, review every value that changes how the app connects, runs, and exposes services. In a managed hosting environment, the safest approach is to treat configuration as part of the release process: check the config files, verify environment-specific settings, and confirm that the Tomcat service, JVM, and web root are aligned with the target deployment. This is especially important when you are deploying into a shared hosting account with a private JVM or a separate Tomcat instance managed through a control panel such as Plesk and a Java hosting extension like My App Server.
For UK-based hosting customers, the main goal is not only to make the application start, but to ensure it behaves correctly for the intended audience, respects local time and locale settings where needed, and matches the platform limits and service controls available in the hosting account. The checklist below covers the config values you should review before going live.
Config values to review before deployment
1. Application environment mode
Check whether the app is running in development, test, or production mode. This is often controlled by an environment variable, a Spring profile, a property in application.properties, web.xml, or a framework-specific config file.
Make sure production mode disables debug features, sample data loaders, mock services, and verbose stack traces. A common mistake is deploying a development profile that still points to test endpoints or exposes internal error details.
2. Java version and runtime compatibility
Tomcat applications can behave differently depending on the Java version used by the JVM. Review:
- JAVA_HOME or the Java runtime path used by the service
- Supported Java release for your framework or app
- Bytecode level expected by the compiled WAR
- Any library compatibility notes for Java 8, 11, 17, or later
If your hosting plan allows choosing between installed Java versions or uploading a custom app server setup, confirm that the selected runtime matches your build. A mismatch here can cause startup failures, class loading issues, or unexpected warnings.
3. Tomcat port bindings and connector settings
Review all values related to the HTTP connector, AJP connector if used, and any internal management ports. Key items include:
- server.port or Tomcat connector port values
- Bind address, if explicitly set
- Shutdown port, if configured
- Proxy-related connector properties
In managed hosting, ports are often assigned or restricted by the platform. Ensure the application listens on the correct internal port and that the control panel service configuration matches the deployed instance. Never assume a port used in local testing will be available in production.
4. Context path and application root
Verify the context path under which the application will be reachable. This can be defined in deployment descriptors, server configuration, or the file name of the WAR package. Check:
- Whether the app should run at the root path or under a subpath
- Any rewrite rules that assume a different path
- Absolute links in templates, JavaScript, and CSS references
- Login redirects and callback URLs
Incorrect context path values are a common reason for broken assets, failed redirects, and 404 responses after deployment.
5. Database connection values
Database settings are among the most important values to review. Confirm:
- DB host
- DB port
- DB name / schema
- DB username
- DB password
- SSL or TLS requirements for database access
- Connection pool parameters
In a hosting platform, database hostnames can differ between local, staging, and production environments. If you use Plesk or a similar control panel, confirm that the database user has the correct permissions and that the app is not using stale credentials from a previous deployment.
6. External service endpoints
Review any URLs or hostnames used for external integrations, including payment gateways, APIs, SMTP relays, identity providers, and object storage. Common values include:
- Base API URL
- Webhook callback URLs
- OAuth redirect URI values
- SMTP host and port
- Message queue or cache endpoints
Make sure test endpoints are not left in place. In UK-focused deployments, also confirm that any endpoint selection matches the customer base and compliance requirements of the application, especially where data processing or regional service availability matters.
7. Time zone and locale settings
Applications that generate invoices, appointments, reports, or audit logs should be checked for time zone and locale values. Review:
- user.timezone or equivalent JVM setting
- Application locale defaults
- Date formatting patterns
- Currency format and decimal separators
For UK deployments, set date handling carefully to avoid confusion between day/month formatting and month/day formatting. Also check whether your app stores timestamps in UTC while displaying local time in the interface.
8. File upload and storage paths
File-based values should be checked before deployment, especially if your app stores uploads, generated reports, logs, or temporary files. Review:
- Upload directory path
- Temporary directory path
- Log directory path
- Whether the path is writable by the Tomcat user
- Disk quota or storage limit assumptions
On shared hosting, paths that worked on a local machine often fail because of permission differences. Ensure the application uses paths allowed by the hosting account and does not write outside the permitted home or application directories.
9. Session, cookie, and security values
Review settings that affect authentication and session handling:
- Session timeout
- Secure cookie flag
- HttpOnly flag
- SameSite cookie policy
- CSRF token configuration
- Password hashing algorithm and iteration settings
If your Tomcat app is behind Apache or another reverse proxy, verify that secure cookies are still being set correctly and that the app detects HTTPS properly. Incorrect proxy settings can cause login issues, redirect loops, or cookies that are not sent back by the browser.
10. Proxy and forwarded header values
When Tomcat runs behind Apache, load balancing software, or platform routing, review the values that tell the application what the original request looked like. These may include:
- X-Forwarded-Proto
- X-Forwarded-Host
- X-Forwarded-Port
- Remote IP configuration
- Proxy name and proxy port settings
This is important if the app generates absolute links, handles OAuth callbacks, or enforces HTTPS. Incorrect forwarded header handling can make the app think it is running on plain HTTP even when users access it securely through the public site.
11. Logging level and log file configuration
Check how much detail the application logs during startup and runtime. Values to review include:
- Log level: INFO, WARN, ERROR, DEBUG, TRACE
- Log file location
- Log rotation settings
- Maximum log size
- Retention count
In managed hosting, overly verbose logs can fill disk space quickly. For production, use a practical logging level and make sure log rotation is enabled where possible. Keep debug logging only for temporary troubleshooting.
12. Memory and JVM options
Tomcat apps can fail under load if JVM values are too low or unstable. Review:
- JVM heap size (-Xms, -Xmx)
- Garbage collection options
- Thread stack size if customized
- Metaspace or permgen-related values, depending on Java version
- Any custom system properties passed at startup
Within a shared hosting account, JVM values should stay within the service limits of the platform. Choose settings that fit the app’s real usage rather than copying a production cluster profile from a larger environment.
13. Cache and background job settings
If your app uses in-memory cache, scheduled tasks, or background workers, check:
- Cache size and expiration values
- Cron expressions or scheduler intervals
- Thread pool sizes
- Retry intervals for failed jobs
- Queue connection settings
Misconfigured background jobs can create duplicate processing, long startup times, or unnecessary resource use. Confirm that scheduled tasks are appropriate for the hosting account and do not overlap with the platform’s own maintenance windows or resource limits.
What to verify in Tomcat config files
web.xml and application deployment descriptors
Check for servlet mappings, welcome files, session timeout values, and security constraints. Confirm that the app’s servlet paths match the deployed context path. Review any hardcoded init parameters that may need to change for production.
application.properties, application.yml, or framework-specific files
These files usually contain the most important environment-specific values. Review datasource properties, mail settings, file paths, feature flags, and service URLs. Make sure production files do not contain local hostnames, test credentials, or disabled security settings.
Tomcat server.xml and related service configuration
If you manage a private Tomcat instance through a control panel, inspect connector definitions, port values, URI encoding, compression settings, and proxy options. Verify that the service starts with the expected Java runtime and that any custom app server settings persist after restart.
JVM startup parameters
Confirm that startup options passed to the service are still valid after deployment. This includes system properties, memory values, timezone settings, and any custom flags used by your application framework.
Recommended deployment checklist
Before you upload the WAR or application files
- Remove development-only profiles and debug flags
- Replace test database and API values with production equivalents
- Check the Java version required by the build
- Confirm the context path and base URL
- Review upload and log paths for write permissions
Before you start the Tomcat service
- Verify JVM memory settings are within the hosting plan limits
- Check port assignments and connector configuration
- Confirm proxy and forwarded header values if Apache is in front of Tomcat
- Validate database credentials and network access
- Make sure the service uses the correct Java version
After the first startup
- Check application logs for warnings and stack traces
- Test login, forms, uploads, and redirects
- Confirm that cookies are secure and sessions persist correctly
- Verify external integrations such as email and payment services
- Check that scheduled tasks and background jobs behave as expected
Common mistakes to avoid
Leaving local values in production
The most common issue is forgetting to replace localhost, 127.0.0.1, or local database credentials. This often causes startup errors or empty service responses after deployment.
Using the wrong Java runtime
Some applications deploy successfully but fail at runtime because the selected Java version does not match the app’s dependencies. Always confirm compatibility before switching the live service.
Ignoring proxy and HTTPS settings
If Tomcat sits behind Apache or another front-end service, missing forwarded header settings can break redirects, login flows, and secure cookies.
Overlooking file permissions
Paths for uploads, temp files, and logs must be writable in the hosting account. Incorrect permissions are a frequent cause of runtime failures in shared hosting environments.
Keeping debug logging enabled
Debug logs are useful during testing, but they should not remain enabled in production unless you are actively troubleshooting a specific issue. They increase log volume and may expose internal details.
How this applies to My App Server and managed Tomcat hosting
If you are deploying through a hosting control panel with My App Server, the main advantage is that you can manage a private JVM and Tomcat instance without handling the full server stack yourself. That makes config review more straightforward, but it also means the values you choose must fit the account’s limits and service controls.
In this setup, pay special attention to:
- Chosen Tomcat version and Java version
- Service start and stop behavior in the control panel
- Custom app server values uploaded manually
- Permissions for app files, logs, and persistent data
- Resource usage such as memory and concurrent threads
This model is well suited to small and medium Java applications, WAR deployments, JSP sites, and servlet-based projects that need a dedicated runtime within a shared hosting account. For that reason, reviewing config values before deployment is the best way to avoid downtime and repeated restarts.
FAQ
Which config file is most important before deploying a Tomcat app?
Usually the application-specific config file is the most important, such as application.properties, application.yml, or a custom environment file. After that, review web.xml, Tomcat connector settings, and any JVM startup options.
Should I keep development and production settings in the same file?
It is better to separate them or use environment-specific overrides. Mixing development and production values increases the risk of deploying test endpoints, debug mode, or unsafe credentials.
What values most often break a Tomcat deployment?
Database credentials, Java version, port settings, context path, file permissions, and proxy-related values are the most common causes of deployment problems.
Do I need to change timezone settings for UK users?
If your app displays dates, schedules, invoices, or logs for UK users, reviewing timezone and locale settings is recommended. Many applications store timestamps in UTC and convert them in the interface, which helps avoid ambiguity.
Why do secure logins fail after moving Tomcat behind Apache?
This usually happens when forwarded header settings or proxy configuration are incomplete. The application may think it is running on HTTP instead of HTTPS, which affects redirects and secure cookies.
What should I check if the app starts but pages show errors?
Review the logs first, then check context path values, database access, external API endpoints, and file write permissions. Startup success does not always mean the application is fully configured.
Conclusion
Before deploying a Tomcat app, review the values that control runtime behavior, connectivity, security, and file access. Focus on Java version, environment mode, database details, Tomcat ports, context path, proxy settings, timezone, and writable directories. In a managed hosting environment with Plesk and a private Tomcat service, these checks help ensure that the app deploys cleanly and runs with the settings intended for production.
When you treat config review as part of deployment, you reduce avoidable errors, make troubleshooting faster, and keep the application stable after launch.