Make yourself at home.
The essentials for getting a project online and keeping it running. All in one place.
A little less guesswork.
Use this guide as a starting point for the private project panel. Register a project, prepare a release, and use the panel to follow what happens next.
Start a project
From a project name to a place of its own.
Ship an update
Prepare your files and check your release.
A private workspace. Access is for authorised users. Keep account details, tokens, and project secrets out of shared files.
Your first project
A short checklist before you publish anything.
Sign in to the panel
Open panel.streetvice.net and sign in with your own account.
Register the project
Choose a recognisable name and the subdomain you want to use. Confirm that its DNS points to the intended server before deployment.
Prepare the release
Build locally if your project needs a build step. Check the archive contents against the project’s deployment settings.
Deploy and verify
Upload the release, follow the deployment status, and open the project URL. Check the main page, assets, and any important actions.
Small releases. Clear checks.
Upload a prepared ZIP archive up to 64 MiB. For a static site, put index.html at the top level of the archive, without an enclosing project folder. Assets can sit beside it in their own directory.
project.zip
├── index.html
└── assets/
├── styles.css
└── app.jsKeep a known working release before uploading a new one. Leave out .env files, private keys, database backups, and local dependency folders.
When something needs attention
Start with the deployment status and logs. Find the first useful error before trying the next action.
| Action | When to use it |
|---|---|
| View logs | Understand a failed deployment or application error. |
| Restart | Restart a project process after fixing its configuration. |
| Rollback | Return to a retained working release after a bad update. |
Check the data too. A code rollback does not necessarily undo database changes. Confirm compatibility before restoring an older release.
Keep the essentials covered.
Make these checks part of every release.
- Use a unique password and enable multi-factor authentication wherever available.
- Store secrets in the server environment, outside public assets and release archives.
- Give each account only the access it needs.
- Review dependency updates and maintain a tested backup before significant changes.
This HTML page is a reference document. Private documentation must be protected by authentication at the server or application layer.
A few common roadblocks
The subdomain does not resolve
Check that the subdomain has the intended DNS record. New records can take time to reach your resolver. Compare the returned address with the project’s server address.
The old page is still showing
Confirm that the new deployment completed for the correct project. Reload without the browser cache, then check that the release contains the updated entry point and assets.
The deployment failed
Read the first error in the deployment logs. Check the archive layout and project settings. For applications with a build step, reproduce the build locally before uploading again.