Before you deploy a Java application on a managed hosting platform, it is worth checking every config value that can affect startup, memory use, database access, session handling, and the way the app connects to Apache Tomcat or a private JVM. In a Plesk-based Java hosting environment such as My App Server, the safest approach is to review both the application’s own properties and the environment values that are injected at runtime. A small mistake in one value can stop the application from starting, break a database connection, or expose sensitive settings in logs.
For UK-hosted Java deployments, the most important rule is to separate environment-specific values from application code. That usually means checking config files, system properties, environment variables, Tomcat context settings, and any values managed through your control panel before each release. This is especially relevant for WAR, JSP, and servlet applications that run under a shared hosting account with a private JVM, where you want predictable behavior without changing the codebase for every environment.
Config values that should always be reviewed
When preparing a Java app for deployment, start with the values that most often differ between development, staging, and production. These are the settings that usually cause the highest number of support issues after a release.
1. Database connection values
Database settings are usually the first place to check. Confirm that the following values are correct and match the production database service:
- JDBC URL — host, port, database name, and protocol
- Username — correct account with the required privileges
- Password — current secret, not an old test value
- Driver class name — for example, the correct MySQL, MariaDB, PostgreSQL, or Oracle driver
- Connection pool values — max pool size, idle timeout, validation query, and connection timeout
If your app uses a Tomcat datasource, review the datasource definition in the context configuration and make sure the JNDI name matches the application reference. A mismatch here often looks like a code issue, but it is usually just a config problem.
2. Application base URLs and hostnames
Any value that defines how the app identifies itself externally should be checked before deployment. This includes:
- Application base URL
- Canonical hostname
- Redirect targets
- Callback or webhook URLs
- OAuth or SSO redirect URIs
These values must be aligned with the live domain and protocol. If the site runs behind Apache with a reverse proxy or passes traffic into Tomcat through a control panel setup, make sure the app knows whether it should generate HTTP or HTTPS links. Wrong base URL values often cause login issues, broken redirects, or mixed-content warnings.
3. Java runtime and JVM memory settings
In a private JVM setup, review values that affect the Java runtime. Common examples include:
- Heap size — initial and maximum memory allocation
- Metaspace size or equivalent JVM memory options
- Garbage collector flags if they are explicitly set
- Java version compatibility — make sure the app is compatible with the selected Java release
- Encoding settings — for example, UTF-8
On hosted environments, memory settings should be conservative and based on the limits of the service plan. Setting an excessively high heap value can prevent the JVM from starting or leave too little memory for the rest of the hosting account. If the platform provides predefined Java/Tomcat versions, use the closest supported version that matches your application requirements.
4. Environment mode values
Always verify whether the app is starting in development, staging, or production mode. Many frameworks use a single config value such as:
app.envspring.profiles.activeNODE_ENVin mixed stacks or integrations- custom flags such as
production=true
Incorrect mode values can enable debug logging, show stack traces to users, disable cache layers, or point the application to the wrong database. For a live deployment, make sure all dev-only settings are disabled.
5. Logging configuration
Logging values should be reviewed carefully because they affect troubleshooting, disk usage, and exposure of sensitive information. Check:
- Log level — INFO, WARN, ERROR, or DEBUG
- Log file path
- Rotation policy
- Retention settings
- Console output settings if logs are captured by Tomcat or the hosting panel
For production deployments, avoid leaving verbose debug logging enabled unless you are actively diagnosing an issue. In a managed hosting account, excessive logs can grow quickly and make it harder to spot the real problem.
Security-related config values to verify
Security values deserve special attention because one wrong setting can expose your application or weaken access control. These settings should be reviewed before every deploy and whenever credentials change.
6. Secrets and API keys
Check all values that authenticate your application to other services:
- API keys
- OAuth client secrets
- JWT signing secrets
- session encryption keys
- mail service credentials
- payment gateway secrets
Never hardcode secrets directly in application source if you can store them in environment-specific values or a protected config location. In a hosting control panel environment, keep secrets outside publicly accessible web paths and make sure they are not included in backup files that can be downloaded by mistake.
7. Session and cookie settings
Session values are commonly overlooked, yet they affect both security and user experience. Review:
- Session timeout
- Cookie domain
- Cookie path
- Secure flag
- HttpOnly flag
- SameSite policy
If the application runs on HTTPS, the cookie configuration should reflect that. Incorrect cookie settings often lead to users being logged out unexpectedly or sessions not being preserved between requests.
8. CORS, CSRF, and trusted origin values
If your app exposes APIs or accepts browser-based requests, review the allowed origins, CSRF trusted hosts, and similar values. Make sure the live domain is present and that any test domains are removed unless they are intentionally required.
For Java web applications that are deployed behind Apache or another front-end service, the trusted origin list should reflect the real public address seen by the browser, not only the internal Tomcat address.
Tomcat and servlet container values to review
When you use My App Server to run Apache Tomcat or a private JVM, there are container-level values that can affect deployment just as much as application properties. These are especially important for WAR-based applications.
9. Context path and deployment path
Check the context path assigned to the app. This controls where the application is reachable, for example at the root domain or under a subpath. Verify:
- the context path is correct
- there are no conflicting context definitions
- the path matches your application’s routing rules
A mismatch between the app’s internal links and the deployed context path can cause 404 errors even when the application itself has started successfully.
10. Resource definitions and JNDI names
If the app uses resources defined in Tomcat, confirm the following:
- resource name
- JNDI lookup name
- driver class
- pool settings
- resource URL and credentials
Application code often expects a very specific JNDI name. If that name changes during deployment, the app may fail at startup or fall back to a non-working default.
11. Server connectors and proxy-related values
In a hosted environment, Tomcat may sit behind Apache or another front-end component. Review values such as:
- connector port
- scheme
- secure flag
- proxy name
- proxy port
These settings help the application generate correct links, detect HTTPS correctly, and handle redirects safely. If they are wrong, the app may think requests are coming over plain HTTP even when the user is browsing via HTTPS.
Framework-specific values that can break deployment
Modern Java apps often rely on frameworks such as Spring, Hibernate, JSF, or Jakarta EE components. Review any values that influence startup and runtime behavior in those frameworks.
12. Spring profile and property source values
For Spring-based applications, check:
- active profiles
- property file locations
- externalized config paths
- mail server values
- cache and queue endpoints
Spring apps can appear healthy while silently reading the wrong property source. Make sure the active profile matches the deployment target and that no development-only config remains in place.
13. Hibernate and ORM settings
Review ORM-related values such as:
- dialect
- schema update mode
- table naming strategy
- connection pool source
- fetch size and batch settings
Incorrect ORM settings may not stop the app immediately, but they can cause performance problems or schema validation errors after startup.
14. File upload and temporary directory paths
Check all paths used for:
- temporary files
- upload storage
- image processing
- report generation
- cache directories
These paths must be writable by the app user and appropriate for the hosting account. Hardcoded paths that work on a local machine often fail in a managed hosting environment because the directory structure is different.
Practical deployment checklist
Use the following checklist before deploying a Java app in a Plesk-hosted Tomcat or private JVM setup:
- Confirm the correct Java version is selected for the application.
- Review all database URL, username, password, and driver values.
- Verify base URL, domain name, and HTTPS-related settings.
- Check memory settings and make sure they fit the hosting limits.
- Disable debug mode and development-only profiles.
- Review secrets, API keys, and other credentials.
- Confirm session cookie settings and security flags.
- Check Tomcat context path and JNDI resource names.
- Validate file and directory paths used by the app.
- Test logs for errors after the first restart.
In a managed hosting account, it is also a good idea to keep a deployment note with the exact values used for each release. That makes rollback and troubleshooting much easier if the app starts behaving differently after an update.
How to review values safely in a hosting control panel
If your Java app is managed through a control panel like Plesk, use a structured approach rather than editing values randomly. A safe process usually looks like this:
Step 1: Export or back up the current config
Before making changes, save the current version of the config files or export the current environment values if the platform provides that option. This gives you a rollback point if the new values do not work.
Step 2: Identify environment-specific settings
Separate settings that should differ between local, test, and live environments. Typical examples are database credentials, base URLs, email delivery settings, and feature flags.
Step 3: Check for duplicate definitions
Many Java apps read values from more than one place. For example, a property may exist in the app package, a Tomcat context file, and an external environment variable. Make sure one source is not overriding another in an unexpected way.
Step 4: Update only the necessary values
Do not change unrelated settings during deployment. Small, targeted updates are easier to test and easier to reverse if a problem appears.
Step 5: Restart the app and review logs
After saving changes, restart the Java service or Tomcat instance using the available service control tools. Then review startup logs immediately. If the app fails, the first error message usually points to the incorrect value.
Common mistakes to avoid
Many deployment problems come from a few repeated configuration errors. Watch out for these:
- Leaving development database credentials in production
- Using the wrong Java version for the application build
- Setting heap memory too high for the available service limits
- Forgetting to update the public base URL after moving environments
- Hardcoding file paths that do not exist in the hosting account
- Using a Tomcat context path that does not match the app links
- Leaving DEBUG logging enabled on a live site
- Storing secrets in publicly readable files
These issues are common because they often do not appear during local testing. They usually show up only after the app is deployed into the actual hosted environment.
FAQ
Which config values are the most important for a Java production deployment?
The most important values are the database connection details, base URL, Java version, JVM memory settings, environment mode, logging level, secrets, and Tomcat context path. These values directly affect whether the app starts and whether it behaves correctly after deployment.
Should I store config values in the code or outside the application?
For most hosted Java applications, environment-specific values should be stored outside the code or injected at runtime. This makes it easier to move between development, staging, and production without rebuilding the application for every change.
What should I check if the app starts but shows database errors?
Review the JDBC URL, username, password, driver class, and any JNDI datasource mapping. Also confirm that the database host, port, and schema name are correct and that the account has the necessary permissions.
How do I know if my JVM memory values are correct?
Start by comparing the heap and metaspace settings with the hosting limits of your service plan. If the values are too high, the JVM may fail to start or become unstable. If they are too low, the application may run out of memory under normal traffic.
Why does my Java app work locally but fail after deployment?
The most common reason is environment differences: path values, database access, Java version, URLs, or permissions are not the same in the hosted environment. Review every config value that depends on the deployment target, not just the code.
What should I check in Tomcat specifically?
Check the context path, datasource definitions, connector and proxy settings, log locations, and any XML or property files that define runtime resources. In a Tomcat-based hosting setup, these values often determine whether the app can start and connect correctly.
Conclusion
Before deploying a Java app, review the config values that control database access, runtime memory, environment mode, security, logging, and Tomcat integration. In a managed hosting setup with My App Server, this is especially important because the application often runs in a private JVM with container-level settings that must match the app’s own properties. A careful config review reduces downtime, avoids startup errors, and makes each deployment easier to support.
If you treat configuration as part of the deployment process rather than an afterthought, your Java hosting setup will be more stable and easier to maintain. For WAR, JSP, and servlet applications in particular, a clean set of environment-specific values is often the difference between a smooth release and a failed startup.