Thanks for quick response Remmelzwaal.

I understand this cannot be extended. But i am looking a solution from nginx by using map method.

For ex. my server is "Server=">">https://server" and another port would be "Server=">">https://server/port=1234", from this i want to use something like "Server=">">https://server/app=xyz".

Also while starting new instance from VTS Name and Port is the mandatory fields, but why can't we use instance name instead of port to access VTS.

If this can be done this would be great feature i guess.

Thanks for quick response Remmelzwaal.

I understand this cannot be extended. But i am looking a solution from nginx by using map method.

For ex. my server is "Server=">">https://server" and another port would be "Server=">">https://server/port=1234", from this i want to use something like "Server=">">https://server/app=xyz".

Also while starting new instance from VTS Name and Port is the mandatory fields, but why can't we use instance name instead of port to access VTS.

If this can be done this would be great feature i guess.

Hi Pavan,

With VTS we have two kinds of access. It looks like you are referring to the UI access.Your idea will be convenient. Creating a VTS instance requires to give an instance name, so this name might be serve as argument to your app parameter.

For the API access the port number is mandatory, because the API connects directly to this port on the give server. This gives the most scalability in VTS. The API is very lightweight and fast. To me that is an very important aspect.

Regards, Erik

Hi Pavan, 

Could you please confirm if below make sense to you?
add a new argument ("InstName") for lrvtc_connect_ex, when port forwarding enabled and InstName set, something like"">https://server/instname=xyz" will be sent to Nginx, in this way, we can map instance name to port  in Nginx side, then tunnel the request to target server.

Hi TinaZZZ ,

I agree with your proposal, but I like to request also for extending the "Server" argument to accept a longer URL:

lrvtc_connect_ex("Server=">https://server/VTS-US", "InstName=MY_PROJECT1", ..., LAST);

or even with port-number in URL

lrvtc_connect_ex("Server=">https://server:8080/VTS-US", "InstName=MY_PROJECT1", ..., LAST);

The use of the extended Server argument implies that we can access VTS via internal refers proxy and route to various VTS servers in multiple AWS regions. The configuration is then of cause not part of VTS's setup but that is OK. When an real Nginx is used by VTS it might be manually configured to do nice things as well.

Let me know what you think.

Hi TinaZZZ 
Yes i am looking for the same, but i agree with JHF Remmelzwaal on extending the server argument which will help us more.