I'm trying to work out the best way to have a staging and production set up on Heroku.
I expected that I could simply create 2 Heroku apps:
Heroku-staging
Heroku-prod
Then in Wappler project settings I have a staging target pointing to Heroku-staging Heroku project ID and the associated URL + a production target pointing to Heroku-prod as Heroku project ID and associated URL.
However, when I publish / deploy, everything always goes to staging even when I push to production.
Each target has it's own database. When I publish and apply database changes, it will ignore the settings and apply whichever database is linked to the deploy target.
So if I deploy to staging I see the staging database on the staging url. If I deploy to production, I see the production database on the staging url and nothing is updated on the production url.
I'm guessing that Wappler is doing something behind the scenes and can only allow one Heroku project per Wappler project.
Is there a better way to approach this setup? I guess I could have production as a separate Wappler project, and pull from Git whenever I want to promote from staging. Is that what others do?
This is close to my method - I don't use separate projects, though. I think that would be a pain in the long run, but hopefully others will share their method.
I use two different git branches (you could use as many as you want, 3 branches could allow 3 Heroku versions: your dev, 1 staging, 1 live)
In Heroku, you can select the branch to pull from to start a new dyno. So I don't ever pull from git to production, I pull from git to a staging server which runs some automated tests to check that critical functions work and give the right outputs.
I have found it to be really flexible and reliable and allows quick and reliable deployments AND rollbacks when a new site doesn't work as expected.
Thanks - so you're publishing to a git branch in Wappler and then pulling from Heroku. That makes sense. The good thing about pulling from Heroku is you're less likely to deploy to production by accident! I haven't really used git branches in Wappler much but I'll look into it.
As an aside, I'm really liking Heroku as a server platform.
You've got it exactly. Things to think about while you're deploying...
I use Bitwarden Secrets Manager to keep environment variables and API keys for production sites -- although you can set git repos to private, if there was ever a leak and the info is crucial to protect, keeping these things in git isn't a great security practice.
You could consider using Heroku's ENV variables or a 3rd party like Bitwarden to store the production "keys to the house" rather than leaving them in a private repo.
SSL is optional on Heroku and I don't know of a way to limit site traffic to SSL-only on Heroku without some effort. If your site needs HTTPS-ONLY, just think about how you want to accomplish limiting traffic -- perhaps a redirect to an error page is an option, but you'll want to solve this early. The only "one click" Heroku app extension that claims to solve this is hundreds USD/month.
Similarly, SSL is automatic and easy on Heroku but I recommend setting a monthly reminder to log in to the admin section of each site and make reminders to check in on your site SSL cert expiration dates to ensure they're automatically renewed.
Keep an eye on usage - both your Postgres and dyno. If you have to go beyond Basic, pricing becomes pay as you go, so be cautious!
I am self hosting on a vps using coolify which is a self hosted alternative to heroku. I felt my post got a bit long winded, so have kept the detail below but here is the summary of my question:
TLDR: I want persistent databases AND branches for each Wappler target.
I'm in a simalar position to the one Paul has outlined and am still unclear on the best way to structure Wappler to future proof the database design and streamline deployments.
Here is my current setup.
Production:
Project on coolify linked to main branch of my repo - Manual deploy (following merge of staging)
Target DB: productoin databse on remote postgreql instance
Staging:
Project on coolify linked to staging branch in repo - Auto deploy via webhook when dev is merged to staging.
Target DB: staging database on remote postgresql instance
Dev:
Local build on laptop
Target DB: local postgresql instance.
What I cant get my head around is how to manage the code push/pull whilst retaining the segregated databases.
I have attempted to use local server options as targets to create a mirror and use a seperate repo all together for staging and prod (which isnt my preferred approach) but that didnt work. And I cant seem to find a way to manage releases/and environments.
Sorry this won't be an answer, but for what it's worth I gave up on Heroku and went back to Digital Ocean where everything worked perfectly.
I have the 2 servers (staging and production) in the resource manager + 3 databases.
I then set the targets in the project settings to the appropriate connections. This works exactly as it should straight away.
Logically, the same should be true for pointing at any server and any database, but it just isn't. The databases were jumping between targets and other weird stuff happened.
I'm sure it's possible but I don't know why it wouldn't work and I don't have the patience for it when DO does the job pretty well. Only gripe I've found with DO is they insist on using their nameservers to manage DNS and it feels incredibly slow to propagate. With Google it was always pretty much instant, but DO often takes a good few hours.
As @Apple has mentioned, the DNS records can be managed by another provider. I use cloudflare to manage DNS records for domains that are registered with different domain registrars.
Sorry I should have been more specific - if you want to use Traefik and add SSL via Let's Encrypt you need to have Digital Ocean nameservers. Or has that changed now? All the comments I've seen suggest that's still the case, and definitely if you want to use a DO load balancer or anything like that it kicks you out if the nameservers are not DO.
@Hyperbytes - I watched your resource manager video on the weekend which was really helpful in getting set up so thank you for pointing me to that (and producing it!). In that you switch the nameservers to DO.
It also got my second droplet target set up without any issues, mainly because you choose some of the exact opposite options vs the Wappler docs Following the docs I was trying to create the server via a docker machine, but the DO droplet options in there don't exist (out of date?) so it fails. You don't use docker machines at all and it works as it should.
This is helpful actually, but I'm still struggling to get my head around the issue.
Aware I am about to hijack this post and my issue is different to yours (you are directly deploying to the cloud provider whereas I am deploying via git) so I'll open a new post.
So does that mean Traefik should work no matter where the DNS is managed? I'm not sure changing the name servers is any simpler than adding an A record
Or is the set up of Traefik more complicated if the name servers are not digital ocean? When I have a bit more time maybe I'll give it a go with a spare domain. I couldn't get it to work before but that was for other user error reasons as well
(I'm not a DigitalOcean customer)
Following the docs I was trying to create the server via a docker machine, but the DO droplet options in there don't exist (out of date?) so it fails. You don't use docker machines at all and it works as it should.