I am currently stuck here at the moment. I haven’t been able to find any valid workarounds for this.
Why is the database connection server action tied to the remote target?
Heroku doesn’t support any of the remote targets Wappler provides. I am currently deploying via git.
What works for me is to remove the dmxConnect/modules/Connections folder from the repository and manually deploy them with their server specific information so you can have different db name or credentials.
I edited the connection file manually but I still get an error referencing the remote target being not valid.
Are you sure you also added the new target and selected in the targets menu?
But then the remote target is not properly setup, as the error says - either the URL, or the remote directory are not properly defined.
Yeah I know. These are just workarounds Ken and I were discussing.
My issue is that Wappler only allows S/FTP or Docker Daemon deploy. So I can’t set a valid remote target for Heroku which doesn’t allow those methods.
Heroku allows GIT deploy or Docker Registry deploy.
My real question is why are the database server actions tied to the remote targets? Lightly related to the original feature request.
Background: I was creating a tutorial to deploy an app in less than 5 minutes in Heroku with custom domain and SSL all for 0€ a month. Pretty sure this will motivate a lot of bubblers 
I managed to do the first part of the tutorial with a static site but hit a roadblock when trying to add a dynamic site pulling info from a DB.
We actually already have different db connections for docker targets 
but will also add it to the rest of the target types, so there is no need for hacking
That is great indeed.
But still I will have a problem setting a remote target for heroku sad face
That is why I am trying to understand why database server actions are tied to remote targets. For sure I am missing something in the equation.
I think we should also allow Git remotes to be defined as targets so you can just switch to them and hit Deploy (Push) to push to the git remote.
This way we can just like docker make the connection files - target dependent, so the right one gets pushed.
That would be perfect! There are a lot of cloud hosts and managed solutions for cloud hosting that allow deploying from source control. So not only Heroku would benefit from allowing this.
In my case I was using Heroku for the tutorial because it allows free hosting and custom domains for unlimited time.
I’ll throw one wrinkle into this in case I’m not alone in my thinking. I use the editor push only to push to github, because I want my workflow when actually updating staging and production to be outside of the editor to avoid problems. For example, if I switch to a production target and then forget to switch back to dev, I might start developing on production. So my workflow is always dev, then push to github, and the from staging or production pull from github so I’m outside of the development flow. Just something to consider.
@JonL silly question could I sign up for Heroku and just deploy my own docker setup and then use it as a remote connection, just like any hosting solution?
Very good point Ken!
We should maybe reconsider the active target methodology.
Maybe we should only have just one working target ( your dev) and the other ones are just for publishing…
But on the other side the active target now also loads the data and rendering from the target so you have live testing…
For static pages you could do it via git repository.
For PHP I haven’t found the way. ASP is not supported by heroku.
Heroku allows 3 methods of deployment.
Git deployment via Heroku CLI
GitHub deployment via webhook.
Docker registry.
At the moment you can’t set a wappler remote target using any of those 3 methods so you can’t use database connections.
For static pages you can push the code to your git repository and then push it to heroku.
In short. No you can’t if you want to use Wappler Server Actions.
Maybe a third option with “Own server” and “Docker Engine” called “Source Control” that uses only dev to edit and remote for publishing.
This new option could be used in the future to manage whatever GIT workflow/s is/are finally decided to go for.
Just don’t forget about those of us that are not smart enough to use Docker and GIT!
True story Brad, lol… I am not sure I am smart enough to figure out how to get my application on the web, lol
