Technical team
Your organization prefers to review the code and deployment requirements before operating an application.
Start with the source and its documentation, then decide whether your team can maintain the running service.
Deployment choices
Is postiz self-hosted right for your team?
Running Postiz on infrastructure you manage changes who handles deployment, data storage, updates, and recovery. This guide separates those responsibilities from the social publishing work you came to do.
This entry point vs the general one
Both routes aim to support social publishing. The difference is whether your team also takes responsibility for the environment that runs the application.
Security reviewer
You need to assess where credentials and publishing data will live, not just whether the interface works.
Treat infrastructure ownership as one part of a wider review of access, secrets, and connected social accounts.
Social media manager
Your immediate goal is to prepare and schedule posts rather than maintain servers.
Map the publishing workflow first so deployment decisions do not obscure the day-to-day task.
Small team
You want to understand the operational commitment before choosing an access route.
Compare the work your team can take on with the simpler path of using a service someone else operates.
The three things only your instance puts in your hands
These are operational controls, not extra publishing features. Each comes with work that the operator must plan for.
-
1
Choose the runtime
Select where the application and its required services run. Check the current project documentation for supported installation methods and dependencies before committing a server.
-
2
Set access and data rules
Decide who can reach the instance, how secrets are stored, and what backup and retention practices apply. Hosting it yourself does not make connected social accounts risk-free.
-
3
Own ongoing maintenance
Plan for updates, monitoring, restore tests, and troubleshooting. A deployment that works on day one still needs attention when software or platform integrations change.
How to start
First decide whether your goal is to operate software or simply publish with it. These nearby guides help frame that decision before you prepare an instance.
A closer look at setup choices
Use this table as a responsibility checklist, not a promise that every deployment has identical features. Verify current requirements in the project's documentation.
| Instance you operate | General access | |
|---|---|---|
| Infrastructure | Your team selects and maintains the runtime. | The service operator maintains its runtime. |
| Installation | Your team follows and validates the supported deployment instructions. | No server installation is needed to begin using the service. |
| Application updates | Your team plans, applies, and checks updates. | The service operator handles application updates. |
| Data location | Determined by the infrastructure and storage you configure. | Determined by the service operator's setup. |
| Backups | Your team defines and tests a recovery process. | Recovery is handled under the service operator's practices. |
| Availability | Depends on your hosting, monitoring, and incident response. | Depends on the service operator's infrastructure. |
| Social platform connections | Still subject to each platform's permissions and integration requirements. | Also subject to platform permissions and integration requirements. |
Limits of running it yourself
More control over the environment does not remove external dependencies or make operations automatic.
1
It cannot remove platform rules
A self-hosted instance still depends on the access and behavior allowed by each connected social network. Hosting location cannot override an integration's restrictions.
What to do instead
Check the current supported connections and permissions for the networks you need before deployment.
2
It cannot maintain itself
Installing Postiz does not automatically cover security patches, database care, monitoring, or recovery after a failure.
What to do instead
Assign an operator and document update, backup, and restore procedures before relying on the instance.
3
It cannot guarantee data security
Controlling the server gives your team decisions to make about exposure, credentials, and access. A poorly secured instance can still put publishing workflows at risk.
What to do instead
Restrict access, protect secrets, review configuration, and test your recovery plan.
Choose your next move
If you mainly need a way to plan and publish social content, explore the available publishing path. If infrastructure control is essential, review the current deployment documentation and confirm your team can own the ongoing work.
Focus on publishing, or prepare to operate
- Clarify who maintains the application
- Check the social connections you need
- Plan security and recovery before deployment
Self-hosting FAQ
Postiz has a self-hosting route for teams that want to operate their own instance. Check the current project documentation for supported installation methods and requirements, since deployment details can change.
Your team runs the application on infrastructure it manages instead of leaving application operations to a service operator. That includes planning access, updates, backups, monitoring, and recovery.
Running your own server is a choice, not the definition of using a social publishing tool. If your goal is simply to prepare and publish posts, compare the general access route before taking on infrastructure work.
Do not assume feature parity from the deployment method alone. Check the current documentation for the functions and integrations you need, then test your intended workflow on the version you deploy.
It lets you choose where your instance and its configured storage run, but connected social networks still process data needed to publish. Review the application's configuration and each platform's permissions to understand the full data path.