Separate the application credential from administration
Create an application-specific database account and verify its actual host, name and permissions with a harmless connection test.
Give an application its own database credentials, matched to the actual database service. It should not use the hosting account password or a server-wide database administrator login. In a DirectAdmin account, database creation and user management depend on the enabled database service and permissions. This guide covers an ordinary site database, not server administration or a database migration.
Before creating anything, identify the application’s supported MySQL or MariaDB version, required privileges and whether it needs a fresh empty database or an imported copy. Record the current database name and backup state if replacing a live application. Avoid placing connection secrets in a web-accessible directory or a support ticket.
Create the database in the supported account interface
Open the database management area available to your DirectAdmin account, often labelled MySQL Management. Create a distinctly named database and a dedicated user; save the generated full names because panels may prefix both with the account name. Generate a strong unique password and store it in the application’s protected secret store. The database host may be localhost or a provider-supplied hostname; use the value your panel or host specifies, rather than guessing.
If the account offers separate user-to-database grants, attach only the new user to the intended database. Grant the smallest set the application needs, such as routine read/write privileges; installation or schema upgrades may need additional DDL privileges temporarily. MariaDB’s GRANT model is scoped by database and operation. If the panel only offers a broad preset, do not claim it implements fine-grained least privilege: ask the host whether a narrower user is supported, and avoid broadening access to unrelated databases.
Configure and test without exposing credentials
Put the exact host, full database name, full username and password in the application’s private configuration. Restrict that file using the application’s deployment guidance. Run the application’s documented connection check or a minimal read query through its own installer. A “user denied” result may mean a wrong host, full prefixed name, password or missing grant; a “database unknown” result points first to the database name or selected server. A timeout or connection refusal points to host/network/service availability rather than a privilege grant.
After connectivity succeeds, exercise one normal read and write operation and inspect the application log. If an import is needed, take a verified backup first and import into the intended database, not an existing production database by name coincidence. Keep the old credential until the application has passed its checks.
For example, a read-only application connection can confirm the host, account and database name; it cannot prove write privileges needed later. Test the smallest authorised write on staging before migration.
Review and recover access
If the application cannot connect, verify the four connection fields against the panel and rotate a newly exposed password rather than sending it to support. If a required operation is denied, identify the exact operation from logs and add only that privilege if your interface permits it. Remove temporary upgrade privileges afterwards when the application supports that model. If a new configuration breaks production, restore the previous protected configuration and database snapshot according to the application’s recovery procedure.
Delete unused users only after confirming no application or scheduled job still uses them. Ask the host for the supported account-level path if the expected controls are unavailable; do not attempt server-wide SQL administration from shared hosting.
Common questions
Can I use phpMyAdmin to create the account? Availability and permissions vary; use the account’s supported management controls.
Should the web application use root? No. Give it a dedicated account scoped to its database.
Why does localhost fail? The provider may specify another database host, or the service may be unavailable; check the account details.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.