Before deploying a Tomcat application, it is worth reviewing the values that can change how the app behaves in each environment. A Tomcat deployment often works on a developer machine but fails in a hosted control panel environment because of differences in JVM options, database connection settings, file paths, secrets, or server-specific environment variables. In a managed hosting setup with Plesk and a private JVM, these values should be checked carefully so the application starts cleanly, connects to the right services, and uses the correct runtime resources.
If you are using a Java hosting platform with a Tomcat service managed through a control panel such as My App Server, the safest approach is to review configuration in layers: application config, environment values, Tomcat service settings, and host-level limits. This helps avoid broken deployments, incorrect database access, and startup errors after a WAR upload or version change.
Review the application-specific configuration first
The first values to check are the ones stored inside the application itself. These are usually the most likely to differ between local, test, and production environments.
Database connection values
Most Tomcat apps rely on database settings in files such as application.properties, application.yml, context.xml, or framework-specific config files. Review the following values before deployment:
- Database host — confirm the hostname or IP is correct for the hosting environment.
- Database name — make sure the app points to the intended schema.
- Username and password — verify credentials are current and stored securely.
- Port — check whether the database uses a non-default port.
- JDBC URL — confirm the full URL format is valid for your database type.
- Connection pool settings — review max connections, timeouts, and validation queries if used.
In hosted environments, a common issue is leaving a localhost database value in place after moving to production. If the application runs in a private JVM on a hosting platform, the app usually needs to connect to the database service provided by the host or to a remote database endpoint that is reachable from the account.
Environment-specific endpoints
Some applications store API endpoints, service URLs, or webhook destinations in config files. Review values such as:
- API base URL
- OAuth redirect URI
- payment gateway endpoint
- email delivery service host
- object storage or file service URL
Make sure these values point to the correct environment. A staging endpoint left in production can cause test transactions, failed callbacks, or inconsistent user data.
Secret keys and tokens
Check all credentials and secrets used by the app, including:
- JWT signing keys
- session encryption keys
- CSRF or app-specific tokens
- SMTP passwords
- third-party API keys
In a managed hosting setup, secrets should not be hard-coded into the WAR file if they can be stored as environment values or separate config files. If the app is redeployed often, keeping secrets outside the package makes updates safer and reduces the risk of accidental disclosure.
Check Tomcat and JVM values that affect startup
When deploying a Tomcat app in a control panel-based Java hosting environment, Tomcat settings and JVM parameters are just as important as application config. These values influence memory usage, encoding, class loading, and startup behavior.
Java version
Confirm that the application is compatible with the selected Java version. Many deployment problems happen because an app was built for one runtime and deployed on another. Review:
- the Java version used during development
- the Java version selected in the hosting panel
- any framework requirements, such as Spring or Jakarta EE compatibility
If the platform allows installing different Java/Tomcat versions with one click, choose the runtime that matches the application as closely as possible. For custom app servers, verify the selected runtime before each deploy.
JVM memory settings
Memory values are important in a private JVM setup. Review:
-Xmsinitial heap size-Xmxmaximum heap size-XX:MaxMetaspaceSizeif relevant- stack size and garbage collection flags if you use custom tuning
Set these values conservatively in shared hosting or managed hosting, because the account will still be limited by platform resources. Too much heap can prevent Tomcat from starting, while too little can cause slow performance or out-of-memory errors under load.
Character encoding
Review default encoding values if the app handles user input, file names, or multilingual content. Check:
file.encoding- request and response encoding filters
- Tomcat connector URI encoding
- database character set compatibility
For web applications handling international traffic, consistent UTF-8 configuration helps prevent broken characters, incorrect form submissions, and parsing issues.
Time zone
Timezone mismatches often cause confusing bugs in logs, scheduling, and reporting. Review:
- JVM time zone
- application date formatting settings
- database server time zone if applicable
- cron or scheduler settings used by the app
If timestamps appear shifted in logs or the UI, check whether the app, JVM, and database are all using the same time zone policy.
Review file paths and storage-related values
Tomcat apps often fail after deployment because a path works locally but not on the hosting account. In a hosted Plesk environment, the filesystem layout is different, so any path-based value should be checked carefully.
Upload directories
Confirm the configured upload path for user files, exports, attachments, and generated documents. Review:
- absolute path versus relative path
- directory permissions
- available disk space
- whether the path is writable by the Tomcat service
A common mistake is storing uploads inside the application directory, which may be overwritten during redeploy. If possible, use a separate persistent location outside the WAR structure.
Log file paths
Check where the application writes logs. Values to review include:
- application log directory
- Tomcat access log path
- error log destination
- rotation policy and file size limits
Logs are critical during deployment and troubleshooting. Make sure the configured path exists and the account has permission to write there. If your hosting platform provides service control in the panel, you should also know where to view startup and runtime logs from the control interface.
Temp and cache directories
Many Java apps use temporary files for uploads, report generation, image processing, or compiled JSPs. Check values for:
- temporary directory
- cache location
- session persistence path
- search index or runtime cache directory
If temp storage is on a small filesystem, deployments can fail later even if the app starts successfully. Review cleanup behavior as well, especially for applications that create many temporary files.
Confirm server-side environment variables
Environment variables are a common way to separate code from configuration. They are especially useful when the same Tomcat app is deployed across test and live environments.
Common environment values to verify
SPRING_PROFILES_ACTIVEor similar framework profile settingsJAVA_HOMEif manually defined by the platformCATALINA_BASEandCATALINA_HOMEwhen custom Tomcat layouts are usedAPP_ENV,ENVIRONMENT, or equivalent profile flags- proxy, mail, and external service variables
Use environment values to separate development, staging, and production behavior. This helps control features such as debug output, mock services, and test credentials without changing the application binary.
Feature flags and debug values
Before deploying, review any values that switch on extra behavior:
- debug logging
- test mode
- maintenance mode
- sample data loaders
- verbose SQL output
Leaving debug mode enabled in production can affect performance and expose sensitive details in logs. On the other hand, disabling useful startup logging too early can make deployment problems harder to diagnose. Review these values before and after the first production start.
Check Tomcat connector and request handling values
Connector settings determine how Tomcat accepts traffic and processes requests. These values matter when an app is deployed behind Apache or another front-end proxy.
Port and protocol settings
Review the connector configuration for:
- HTTP or HTTPS port
- AJP settings, if used
- redirect ports
- proxy attributes
If the application is served through Apache in front of Tomcat, make sure the forwarded host and protocol values are correct. Otherwise, generated links, redirects, and secure cookies may behave incorrectly.
Proxy and forwarded headers
Review values related to proxy awareness, such as:
X-Forwarded-ForX-Forwarded-ProtoX-Forwarded-Host- proxy port and scheme settings
This is especially important if SSL is terminated before Tomcat. Incorrect proxy configuration can lead to mixed-content warnings, bad redirects, or login issues.
Session configuration
Check session-related values if the app stores sensitive or long-lived user state:
- session timeout
- cookie name and domain
- secure and HttpOnly flags
- session persistence options
Match these values to the deployment context. If the app is behind a front-end server, cookie and secure flag handling should be tested after deployment.
Validate permissions and ownership-related values
In a managed hosting environment, a Tomcat deployment can fail even when the config looks correct if the service account cannot read or write the expected files. Review the values and assumptions that affect access control.
Writable locations
Make sure the following are writable by the Tomcat service:
- log directories
- temp directories
- upload storage
- cache folders
- generated report output locations
Readable config files
Config files should be readable by the service process but protected from public access. If your deployment stores separate property files outside the web root, confirm the paths are correct and that permission changes did not break the app after upload.
Deployment checklist for Tomcat apps on managed hosting
Use this practical checklist before you click deploy or restart the service:
- Confirm the selected Java version matches the app build requirements.
- Review all database host, name, user, password, and JDBC URL values.
- Check all environment-specific endpoints and web service URLs.
- Verify secret keys and API tokens are current and stored safely.
- Inspect heap and JVM options for the available account limits.
- Confirm file paths for uploads, logs, cache, and temp data.
- Check encoding and time zone settings for consistency.
- Review proxy, connector, and session settings if Tomcat runs behind Apache.
- Make sure writable directories exist and permissions are correct.
- Validate that debug or test flags are disabled for production.
In a control panel workflow, it is often best to change one group of values at a time and restart the service after each significant change. That makes it easier to identify the exact setting that caused a problem.
Recommended value types to store outside the WAR file
For maintainability, separate values that change by environment from application code whenever possible. Good candidates include:
- database credentials
- SMTP settings
- API tokens
- external service endpoints
- runtime profiles
- file paths
- feature flags
Keeping these values outside the packaged application makes deployments safer on a Tomcat hosting platform. It also reduces the chance that a new WAR upload overwrites a production-specific setting.
Common mistakes to avoid
Most Tomcat deployment issues related to config values come from a few repeated mistakes:
- Using localhost for database or service hosts in production.
- Leaving test credentials in live config files.
- Hard-coding file paths that do not exist on the hosting account.
- Setting memory values higher than the account can support.
- Forgetting to update the Java version after rebuilding the app.
- Leaving debug logging enabled after launch.
- Ignoring proxy and HTTPS settings when Tomcat sits behind Apache.
- Storing user-generated files inside directories that are replaced on deploy.
These issues are usually easy to prevent with a short pre-deployment review.
FAQ
Which config values matter most before a Tomcat deploy?
The most important values are database settings, environment variables, Java version, heap size, file paths, secret keys, and proxy-related connector settings. These are the values most likely to break an application after deployment if they are wrong.
Should database credentials be inside the WAR file?
It is better to keep them outside the WAR file whenever possible. In a managed hosting setup, separating credentials from the package makes updates safer and helps avoid accidental exposure during redeployments.
Why does my app work locally but not on the hosting platform?
Local environments often use different Java versions, path structures, database hosts, and file permissions. The app may also rely on local config values that are not valid in the hosted Tomcat service. Compare all environment-specific values before deployment.
What should I check if Tomcat fails to start after changing config?
Check the Tomcat logs first, then review Java version compatibility, JVM heap values, invalid paths, missing environment variables, and broken syntax in config files. A single incorrect value can prevent the service from starting.
Do I need different values for development and production?
Yes. At minimum, database endpoints, credentials, API tokens, debug flags, and file storage paths should usually be different. Production should use secure, stable values while development can use safer test-specific settings.
How does this apply to My App Server in Plesk?
With a My App Server setup, the Tomcat service and private JVM are managed through the control panel, so you should review both application config and service-level values in one place. That includes the selected Java/Tomcat version, memory limits, environment values, and any custom app server configuration used for your deployment.
Conclusion
Before deploying a Tomcat app, review every value that can change between environments: database details, API endpoints, secrets, JVM options, Java version, file paths, encoding, time zone, connector settings, and permissions. In a managed hosting or Plesk-based Java hosting setup, this review is especially important because the application runs inside a controlled service with account-specific limits and paths.
A short configuration check before deployment saves time later, reduces startup errors, and makes Tomcat hosting much easier to manage. If you keep environment-specific values separated from application code and verify them consistently, your WAR deploys will be safer and more predictable.