Map environments and access first
Describe where code is written, images are built, tests run and production releases are approved. Development, staging and production should not share the same secret keys or database. Each environment needs a clear purpose and a rule for what data may enter it. A production copy containing personal records is not a harmless test sample. Give people and automation only the permissions needed for their role, with a defined way to remove those permissions.
A VPS project can often use a simple model: a versioned repository, repeatable build, Compose and one documented release procedure. A more complex orchestrator is not automatically safer. What matters is knowing who controls the server, image registry, DNS, backups and access keys. Keep these roles separate from the public site. An account that reads content should not also have permission to change infrastructure.
The artefact must match approved source
Build from a specific code revision and record the identity of the resulting artefact. To restore a release, you need to know which image, database schema and configuration belonged together. NIST's SSDF describes protection of software components from unauthorised change and integrating secure practices into development. For a small team that means reviewed changes, a repeatable build and a proportionate dependency record, rather than a collection of signing services without an owner.
Before release run tests for critical journeys, type and dependency checks, and verify that local key files were not copied into the image. Automated checks must fail visibly. An exception needs a reason, approver and review date. Running a command in the new version without reading its migration step is not a release procedure. Treat a configuration change like a code change because it can alter public exposure and access to data.
Secrets do not belong in the repository or logs
Keep passwords, API keys and signing material outside versioned files. Docker documents how Compose secrets provide file access to a secret only for assigned services, which can reduce accidental exposure through process environments. The chosen method must suit the application and operating procedure. A local environment file may be practical during development, but on a public server you must assess who can read the file or inspect the resolved configuration. Never paste it into an issue or screenshot.
Give every key an owner, purpose, storage location and rotation procedure. After a leak, removing a line from the newest commit is not enough; revoke the compromised credential at its provider and check access history. Log an operation identifier and error type rather than full request headers or tokens. Apply the same rules to backups and administration scripts. Their copies may contain more sensitive data than the public application.
A release gate before deployment
Check that a version passed functional tests, critical access works only for the proper roles and expected security settings are active. OWASP ASVS structures requirements for verifying web applications; the exact scope must follow the product and its risk. Review authentication, authorisation, input validation, file handling and outbound calls where applicable. Keep evidence of the result with the relevant revision so a later team can see what was checked.
The gate also covers operations: health checks, error monitoring, backup location and a person available during the first hours after release. For database changes, check compatibility between old and new application versions. Define success in advance through error counts, latency, completed important transactions and queue state. If you cannot measure the result, a faulty release may remain online simply because the container reports that it is running.
Every release needs a route back
Use gradual release where volume and architecture permit. A smaller site may need only a prepared previous version, a short verification window and a way to revert a container or routing. For data migrations, reverting an image is insufficient. Design table changes compatibly, separate expensive transformations and prepare recovery for irreversible steps. Test a rollback in an environment similar to production before the first live release.
Record who decides on rollback and how duplicate processing is prevented during a switch. After returning, compare queue, database and external-system state. A user may have completed an operation that the older version does not understand; that case needs investigation. Without this view, rollback is only a file change, not service recovery. Each incident should produce a concrete test or check that makes the same class of failure less likely.
Monitoring and recovery are part of the solution
Monitor external availability, application errors, database state, disk capacity and the age of the last verified backup. An alert needs a recipient and a procedure for judging urgency. Thousands of alerts without ownership reduce security because important signals disappear in the noise. Connect logs with request identifiers and review retention. Record failed admin sign-ins and unexpected configuration changes separately from ordinary traffic.
A backup is functional only when the required data can be restored within an acceptable time. Verify configuration, application version and keys needed to read it. Rehearse recovery away from the production database and then check specific records and important functions. Set acceptable data loss and return time for each data type according to actual impact. If a recovery plan depends on one person remembering a password, it cannot be handed over reliably.
Acceptance and responsibility boundaries
An early pilot can deploy a nonproduction version and exercise the full path from repository change to alert and rollback. Deliver a short tested runbook, access list, test evidence, backup map and named owners for each step. This page does not claim EXCOIN has certified a client environment or can guarantee immunity to attacks. Specific security needs and any external testing scope depend on the system, data and contract.
At handover, give the operator a realistic case: errors rise after release, the database is healthy, but one important journey fails. Can they identify the running version, stop the new traffic, restore the right artefact and investigate pending requests? If yes, the deployment approach has practical value. If success depends on an undocumented intervention by the original developer, work on safe operations is not yet complete.