Before you deploy a Java application, it is worth reviewing every configuration value that can affect startup, runtime behaviour, and connectivity. In a managed hosting environment, especially when you run your app through Plesk and a service such as My App Server, small mismatches in environment values, JVM options, or Tomcat settings can prevent the application from starting or can cause hidden issues after deployment.
The safest approach is to treat configuration review as part of the deployment checklist. That means checking not only the application’s own properties file, but also the values supplied by the hosting platform, the servlet container, the database layer, and any external services the app depends on. This is particularly important when you host a WAR, JSP, or servlet-based application on a private JVM, because the service may run with its own Java version, memory limits, and port assignment.
What configuration values matter most before deployment
When preparing a Java app for hosting, focus on the values that directly affect where the app connects, how it starts, and what environment it expects. The most common groups are:
- Application properties, such as
application.properties,application.yml, or custom config files - Environment variables used by the app or framework
- JVM options, such as heap size and garbage collection flags
- Tomcat or servlet container settings
- Database connection values
- API keys, secrets, and service credentials
- File paths, upload directories, and log locations
- Port numbers and context path values
In a hosting platform with Plesk and My App Server, these values are often split across the application package, the control panel, and the managed service configuration. Reviewing them together helps avoid conflicts between what the code expects and what the hosting environment actually provides.
Review the application profile and active environment
Many Java frameworks use environment-specific profiles to load different settings for development, staging, and production. Before deployment, confirm which profile the app will use on the hosting account.
Check the active profile value
Look for values such as:
SPRING_PROFILES_ACTIVEquarkus.profilemicronaut.environmentsapp.environment
If the wrong profile is active, the app may try to connect to a test database, use debug logging, or load development-only credentials.
Verify config file selection
Some applications rely on file names such as:
application-dev.propertiesapplication-prod.propertiesconfig.yml.env
Make sure the deployment package includes the correct file and that the runtime is pointed at the right one. In a managed hosting setup, this is especially relevant when the app is deployed through Plesk and a Java service such as Tomcat is started separately from your local machine.
Review database connection values carefully
Database settings are one of the most common causes of deployment problems. Even when the application itself is correct, a wrong hostname, port, schema name, or password will stop it from starting or from serving requests properly.
Values to confirm
- Database host
- Database port
- Database name or schema
- Username and password
- JDBC URL format
- SSL and encryption flags
- Connection pool limits
Typical values to inspect in a Java app include spring.datasource.url, spring.datasource.username, and spring.datasource.password, or equivalent settings in your framework.
Confirm JDBC URL syntax
Many deployment issues come from a malformed JDBC URL. Make sure it matches the database engine and the expected format. A small typo, such as the wrong protocol prefix or an extra slash, can break connectivity immediately.
Check SSL-related settings
If the database requires encrypted connections, verify that the relevant trust settings are in place. If your hosting environment uses a database service with SSL enabled, the application may need extra flags or certificates to connect successfully.
Review JVM options before you start the service
When you run a private JVM or Tomcat instance in a hosting account, JVM options can be as important as the application code. Incorrect values can cause startup failures, memory pressure, or unstable performance.
Key JVM values to review
- Initial heap size
- Maximum heap size
- Stack size
- Garbage collection options
- Character encoding
- Timezone
- Debug flags
Common examples include -Xms, -Xmx, -Dfile.encoding, and -Duser.timezone. These should match the application’s needs and the resource limits of the hosting account.
Align memory settings with hosting limits
On shared hosting or managed Java hosting, you should not set heap sizes larger than the service can safely use. Review the service limits in the control panel and adjust the JVM settings accordingly. A Java app that starts with too much memory may fail to launch or may affect other services in the same account.
Remove development-only flags
If you have debugging flags, remote debugging ports, or verbose logging options enabled during development, remove or disable them before production deployment unless they are intentionally needed. Leaving them on can expose sensitive details or slow the app down.
Review Tomcat-specific configuration values
If your application runs on Apache Tomcat through My App Server, Tomcat configuration deserves special attention. The web app may deploy correctly, but still fail if the container settings do not match the app’s assumptions.
Important Tomcat settings to verify
- Server port
- Shutdown port, if used
- HTTP connector port
- HTTPS connector port, if configured
- Context path
- Session timeout
- Upload size limits
- Default character encoding
In a Plesk-based environment, these values are usually managed through the Java service configuration rather than directly edited in a global server profile. Confirm the active settings in the control panel before deploying the WAR file.
Check context path and application path
A frequent issue in Tomcat hosting is a mismatch between the deployed context path and the URLs used by the application or frontend. If your app assumes it is available at the root path but it is deployed under a subpath, links, redirects, and API endpoints may fail.
Verify session and upload limits
If your app handles login sessions, file uploads, or long-running forms, review session timeout and upload size limits. A value that is too low can cause users to lose work or file uploads to fail.
Review application secrets and credentials
Secrets should always be checked before deployment, not after. This includes database passwords, SMTP passwords, API tokens, OAuth client secrets, and any other private values the app needs.
What to confirm
- No development credentials are included
- No placeholder values remain in the production config
- Secrets are stored in the correct location
- Secrets are not committed into the application archive if avoidable
- File permissions protect sensitive values
If your hosting platform supports environment variables or service-specific configuration, use those where possible instead of hardcoding secrets in application files. This makes it easier to rotate credentials without repackaging the app.
Review file paths, working directories, and permissions
Java applications often rely on filesystem paths for logs, uploads, reports, cache files, or imported data. These paths may work locally but fail in hosting if they point to a directory that does not exist or cannot be written by the service user.
Check these path-related values
- Upload directory
- Log directory
- Temporary directory
- Config file path
- Static content path
- Backup or export path
Make sure the paths are valid in the hosting account and writable by the Java service. If your app uses relative paths, confirm the working directory that Tomcat or the private JVM uses at startup.
Avoid hardcoded local paths
Do not leave paths such as C:\..., /Users/..., or other local development references in the deployment package. Replace them with server-appropriate paths that fit the hosting environment.
Review ports and endpoint values
Java applications can fail in subtle ways if service endpoints do not match the deployed environment. This includes internal ports, webhook URLs, and external API endpoints.
Internal service ports
If the app connects to another local service, confirm that the target port is correct and available. On hosting platforms, you should avoid conflicts with the HTTP service port assigned to Tomcat or Apache.
External URLs and callback endpoints
Check values used for:
- Login redirects
- OAuth callbacks
- Payment gateway notifications
- Webhook targets
- SMTP relay hosts
These values should reflect the deployed domain and protocol. If your site uses HTTPS, any callback URL should also use HTTPS to avoid mixed-content or redirect problems.
Review logging configuration
Logging is essential during deployment, but overly verbose logs can fill disk space or expose too much detail. Before going live, confirm the logging configuration is appropriate for production use.
Key logging values
- Log level
- Log file path
- Log rotation policy
- Maximum log size
- Retention count
In managed hosting, logs are often the first place to look when a Java app fails to start under My App Server. Make sure the app writes logs to a directory you can access through the control panel or service tools.
Review character encoding and locale settings
Character encoding issues can appear as broken accents, malformed form input, or incorrect sorting. Before deployment, confirm the app and JVM use the same encoding expected by your content and database.
Settings to inspect
file.encoding- Default locale
- Request and response encoding
- Database collation and charset
For multilingual applications, this step is particularly important. A mismatch between UTF-8 settings in the app and a different database encoding can cause data corruption or display issues.
Review security-related values
Before deploying, confirm that security controls are correctly set for the target environment. This includes session settings, allowed hosts, CSRF settings, and secure cookies.
Typical security values
- Allowed domains or hostnames
- Cookie secure flag
- Cookie HTTP-only flag
- CSRF token settings
- Password policy values
- Session timeout
If the app is moving from development to production, some settings must be tightened. For example, debug endpoints, open CORS rules, or relaxed cookie settings should be reviewed and adjusted before launch.
Review mail and notification settings
Many Java apps send password resets, invoice notifications, or support alerts. If email is part of the application flow, verify the SMTP configuration before deployment.
Check these values
- SMTP host
- SMTP port
- Username and password
- TLS or STARTTLS settings
- From address
- Reply-to address
Incorrect mail settings are often overlooked because the application may appear to work until it needs to send the first message. Test the email flow as part of the deployment process.
Practical deployment checklist for Java apps on managed hosting
Use the following checklist before you click deploy or start the service in Plesk:
- Confirm the active environment profile.
- Review database host, name, user, password, and JDBC URL.
- Check JVM memory and encoding options.
- Verify Tomcat context path and port-related values.
- Remove development-only debug flags.
- Validate file paths for logs, uploads, and temp files.
- Confirm secrets are stored securely.
- Check mail, API, and webhook endpoints.
- Review character encoding and locale.
- Test the application start-up logs after deployment.
In My App Server, this process is especially useful because you can manage a dedicated Java service inside the hosting account and make configuration changes without needing a separate enterprise application server setup. That gives you practical control over the Java version, the Tomcat instance, and the service lifecycle while keeping deployment manageable.
Common mistakes to avoid
Leaving development values in production
One of the most common mistakes is deploying with local database addresses, test profiles, or debug mode still enabled. Always scan config files for temporary values before release.
Ignoring service limits
Setting memory, thread, or file limits too high can cause the app to fail in a hosted environment. Check the allowed resource ranges in the control panel before editing JVM options.
Hardcoding environment-specific paths
Local paths and machine-specific values should be replaced with configurable paths that work in the hosting account.
Mixing HTTP and HTTPS settings
If the application uses secure URLs, cookies, or redirects, make sure the configuration matches the live protocol. Inconsistent settings can cause login and callback issues.
FAQ
Should I review only the application properties file?
No. You should review application properties, environment variables, JVM flags, Tomcat settings, database values, and any external service credentials. A Java deployment can fail even when the main config file is correct.
What is the most common configuration error before deployment?
Database connection values are among the most common problems, followed closely by wrong environment profiles and incorrect JVM memory settings.
Can I use the same config for local and hosted environments?
Usually not. Local settings often include different database hosts, file paths, and debug options. Use separate values for development and production.
Where should I store secrets for a Java app on hosted infrastructure?
Use secure environment variables or platform-supported configuration locations where possible. Avoid hardcoding passwords and API keys directly into the application archive.
How do I know if Tomcat settings are causing the problem?
Check the service logs after startup. If the app fails during deployment, port conflicts, context path mismatches, or memory issues are common Tomcat-related causes.
What should I verify first if the app starts but does not work correctly?
Start with database access, API credentials, and base URL values. These are frequent causes of partial functionality after deployment.
Conclusion
Before deploying a Java app, review every value that can affect runtime behaviour, service access, and security. In a managed hosting environment with Plesk and My App Server, that means checking application profiles, database settings, JVM options, Tomcat configuration, secrets, file paths, and external endpoints together. A careful review reduces downtime, avoids preventable startup errors, and makes the deployment process much smoother for Java, Tomcat, JSP, and servlet hosting workloads.
If you use a private JVM or a dedicated Tomcat instance inside your hosting account, treat configuration review as a required step, not an optional one. It is the fastest way to make sure the application starts cleanly and behaves as expected in production.