This tutorial by Instatic focuses on the specific task in the title. Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
Below is a demonstration using a test environment and revocable data. When accounts, keys, machine control, investments or emergency communications are involved, manual confirmation must be done.
Decide first whether SQLite or Postgres
This section only deals with “Deciding between SQLite or Postgres first”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For Instatic, this boundary must be considered when judging the results: Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Why can you choose SQLite for stand-alone trial?
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is “Why can you choose SQLite for a single-machine trial?” to get verifiable results, rather than the command just not reporting an error.
Why evaluate Postgres for long-term use by many people
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Why evaluate Postgres after long-term use by many people | Clear input, output and permission scope | Tool automatically expands the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Check environment variables before starting Docker Compose
This section only deals with “Checking environment variables before starting Docker Compose”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For Instatic, this boundary must be considered when judging the results: Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Only bind the application port to the loopback address
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is to “only bind the application port to the loopback address” to obtain a verifiable result, rather than the command just not reporting an error.
Check the migration log after the first startup
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Check the migration log after the first startup | Clear input, output and permission scope | The tool automatically expands the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Create test content and upload an attachment
This section only deals with “creating test content and uploading an attachment”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For Instatic, this boundary must be considered when judging the results: Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Caddy only proxies application ports
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion criterion is that “Caddy only proxies application ports” and obtains verifiable results, rather than that the command happens to report no errors.
HTTPS normal does not mean the application is safe
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Normal HTTPS does not mean that the application is secure | Input, output and permission ranges are clear | Tools automatically expand the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Database backup and file backup are performed separately.
This section only deals with “separate execution of database backup and file backup”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For Instatic, this boundary must be considered when judging the results: Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Do an empty directory recovery drill
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is to “do an empty directory recovery drill” and obtain verifiable results, rather than the command just not reporting an error.
Fixed the current label before upgrading the image
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Fixed the current label before upgrading the image | Clear input, output and permission scope | The tool automatically expands the scope of operation |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Do not restart repeatedly when migration fails
This section only deals with “Don’t restart repeatedly when migration fails”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For Instatic, this boundary must be considered when judging the results: Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
How to locate concurrency in SQLite lock errors
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is to obtain verifiable results on “How to locate concurrency in SQLite lock errors”, rather than the command not reporting an error.
Hierarchical troubleshooting of Postgres connection failure
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Hierarchical troubleshooting of Postgres connection failure | Clear input, output and permission ranges | The tool automatically expands the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Final recovery checklist after going online
This section only deals with the “final recovery checklist after go-live”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For Instatic, this boundary must be considered when judging the results: Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
How to locate upload directory permission errors
It is recommended to execute in the following order:
- Check the actual version and source.
- Use a test account, test directory, or test device.
- Perform an undoable action.
- Save the output, exit code, or screenshot.
- Revert the changes and re-verify.
|
|
The completion standard is “How to locate the upload directory permission error” to obtain a verifiable result, rather than the command just not reporting an error.
Is the real client IP after reverse generation credible?
| Check items | Passing criteria | Stop signal |
|---|---|---|
| Is the real client IP after reverse generation trustworthy? | Clear input, output, and permission ranges | The tool automatically expands the scope of operations |
| Source | Can return to the official warehouse or original data | Rely on unknown mirrors or second-hand conclusions |
| Security | No secret value in log | Token, cookie or private data present |
| Recovery | Ability to return to pre-execution state | No backup or undo methods |
|
|
When a stop signal appears, resume first and do not continue to the next step.
Confirm that the backup is readable before deleting the test instance
This section only deals with “confirm that the backup is readable before deleting the test instance”. Save the current state first and then run the minimal test. Do not change multiple conditions at the same time.
|
|
For Instatic, this boundary must be considered when judging the results: Self-hosted Instatic involves applications, databases, uploaded files, and reverse proxies; backups that only cover the database will leave attachments and configuration gaps that cannot be recovered.
If the results are not repeatable, record the version, input, and logs, then narrow the scope of the test.
Final check of Instatic
- The versions and sources used are documented.
- Test input and formal data have been isolated.
- Commands, configurations and actual output can correspond.
- The failed path was actively tested at least once.
- Keys, accounts and private data do not enter Git or logs.
- There are clear actions for upgrading, stopping and resuming.
If you still can’t explain how the results are produced, continue to keep Instatic in the test environment without extending the permissions or replacing the existing stable process.